bsdtar vs. NFS: Couldn't visit directory: No such file or directory
David Wolfskill
david at catwhisker.org
Tue Nov 25 18:15:53 PST 2008
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
...
tar: sb2/src/bsd/lib/libgdchart: Couldn't visit directory: No such file or directory
tar: sb2/src/bsd/lib/libgd: Couldn't visit directory: No such file or directory
@ 1227665194 [Tue Nov 25 18:06:34 2008] Ending "tar zcpf sb2.tgz sb2" in /homes/dwolf/bspace
(I elided a couple dozen or so of the whines.)
I looked from a different NFS client host and saw each of the allegedly
nonexistent filles or directories for which I cared to look.
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.)
Now, the reason I was doing this was to make a pristine archive of
that hierarchy, so after I did some things in the hhierarcchy, I
could blow it away, restore from the pristine archive, and repeat
the performance: the intent is to be able to get reproducible results
(both timing and output) from several repetitions of a several-hour-long
process.
The script I cobbled up to do the work checks the status code when
tar(1) completes, and terminaates the process if it sees that there
was a non-zero status code at that point (among others).
Since tar(1) is exiting with a status code of 0, the script has no
way to tell that something went (dreadfully) wrong in trying to
create the archive, and blithely carries on... which is doomed to
failure.
Some questions:
* 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.
* 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)?
* 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?
* Might it help to defer the compression to a point subsequent to the
creation of the archive proper?
Thanks....
Peace,
david
--
David H. Wolfskill david at catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20081126/b7e95666/attachment.pgp
More information about the freebsd-stable
mailing list