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