Date: Wed, 26 Nov 2008 10:49:24 -0800 From: Tim Kientzle <kientzle@freebsd.org> To: David Wolfskill <david@catwhisker.org> Cc: stable@freebsd.org Subject: Re: bsdtar vs. NFS: Couldn't visit directory: No such file or directory Message-ID: <492D9A34.6020509@freebsd.org> In-Reply-To: <20081126021551.GA83287@bunrab.catwhisker.org> References: <20081126021551.GA83287@bunrab.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?492D9A34.6020509>