David Wolfskill wrote:
Running an 8-core RELENG_7_1/i386 system (updated this morning), trying
to tar up a directory hierarchy rooted at a directory nnamed "sb2" in a
file system that is NFS-mounted (exported from a NetApp Filer); I have
the following logged:
@ 1227662967 [Tue Nov 25 17:29:27 2008] Starting "tar zcpf sb2.tgz sb2" in
/homes/dwolf/bspace
tar: sb2/src/vendor/berkeley-db/os/CVS: Couldn't visit directory: No such file
or directory
tar: sb2/src/vendor/berkeley-db/mutex: Couldn't visit directory: No such file
or directory
...
I then see that tar(1) took 1924.05 seconds to do this, and exited with
a status code of 0. (I ran it under the auspices of /usr/bin/time.)
I agree that this does seem wrong.
Since you explicitly called out the time required for the
operation, did you have any concerns about the performance?
* Is it both intentional and appropriate for tar(1) to exit with a
status code of 0 in this circumstance? The code that issues the
whine is in write.c, around lines 662-663 in rev. 1.63.2.10.
As you pointed out, automated scripts need to be able
to trust the exit code to know whether everything
went okay. Based on that, I would agree this is inappropriate,
though perhaps someone has an argument to the contrary.
I'll take a closer look.
* It may be argued that telling tar(1) to go look in a file or
directory, then claiming that it doesn't exist, is rather bad form;
I certainly wouldn't ddisagree, yet I don't know what I can do to
prevent it. I'm certain that it's not a case of some process on
some other NFS client modifying that directory hierarchy during the
tar(1) run. Is there anything that may be done to prevent it? Is
there something broken in FreeBSD's NFS client implementation as
of RELENG_7_1 that might be causing this? Perhaps it is an artifact
of some sort of caching?
* Does it matter that the NFS mount is being "managed" by amd(8)?
No idea about the underlying cause. Hopefully someone else
can chime in about whether there is some known NFS issue that
may be at work here.
* Am I using tar(1) appropriately? Is there some other tool (e.g.
cpio(1)) that might have more appropriate behavior for the intended
usage?
tar(1) seems appropriate here.
* Might it help to defer the compression to a point subsequent to the
creation of the archive proper?
That should have no effect.
Only odd thing I see in your usage is that the 'p' modifier
has no effect when used with 'c'. (bsdtar always records
everything it can when creating the archive, limited only by
what the underlying format can represent.)
If you can reproduce this on a smaller test case, I think
some of the folks working on NFS support might find detailed
tcpdump output to be interesting reading.
Tim
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
