mkext vs. tar for custom install

mkext vs. tar for custom install

[Steve]

I'm getting ready to load the CDROM onto my new PC (kfs filesystem), and
I can't use c:/plan9/386/bin/build because I only have 400Meg in my Plan9
partition. I want to load everything except /mips, /sparc and /68020.

If I did this with tar, I'd try:
% {cd /n/cdrom; tar c 386 sys lib acme rc adm} | {cd /n/kfs; tar xv}

If I did it with mkfs, I'd try:
% disk/mkfs -a -s /n/cdrom /tmp/myproto |disk/mkext -uv -d/n/kfs

Which of the above would be the preferred method, and why?
Would they both set the ownerships and modification times properly?

By the way, the manpage for mkext(8) says the '-u' option can only be used
when initializing a new fs(f) file system, but I find the following 
in /sys/lib/pcdist/src/build.c, where it un-packs the 4 floppies:

       sprint(buf, "vdexpand < /n/a/disk%d.vd | disk/mkext -uv -d/n/kfs", disk);

Here, it is using a kfs file system with the '-u' option, in contradiction
to the restriction in the manpage.
Is the manpage out of date, or is build.c breaking the rules somehow?

mkext vs. tar for custom install

[forsyth]

>>Is the manpage out of date, or is build.c breaking the rules somehow?
{disk/kfscmd allow} puts disk/kfs into the same state as a full-blown file server
during its initial load (or `allow' at config level).  (the command is
issued by startkfs in build.)

disk/mkext -u will set owners, groups, and file times correctly to those
on the CDROM.  tar won't.  although it probably doesn't affect the distribution,
tar also has several other restrictions (eg, path name limits) that don't apply
to mkext.