Date: Tue, 25 Nov 2008 18:15:51 -0800 From: David Wolfskill <david@catwhisker.org> To: stable@freebsd.org Subject: bsdtar vs. NFS: Couldn't visit directory: No such file or directory Message-ID: <20081126021551.GA83287@bunrab.catwhisker.org>
next in thread | raw e-mail | index | archive | help
--8QEjIIRQMK54tiVT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 f= ile or directory tar: sb2/src/vendor/berkeley-db/mutex: Couldn't visit directory: No such fi= le 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 direc= tory @ 1227665194 [Tue Nov 25 18:06:34 2008] Ending "tar zcpf sb2.tgz sb2" in /h= omes/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 --=20 David H. Wolfskill david@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. --8QEjIIRQMK54tiVT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkkssVcACgkQmprOCmdXAD288QCfWDpCK2ey/xFDg0O6UqNDHdq+ KkkAnRD9peNCf95faQNoJ6sNTLQ12Oi6 =ssDU -----END PGP SIGNATURE----- --8QEjIIRQMK54tiVT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081126021551.GA83287>