bsdtar vs. NFS: Couldn't visit directory: No such file or
directory
David Wolfskill
david at catwhisker.org
Wed Nov 26 11:04:15 PST 2008
On Wed, Nov 26, 2008 at 10:49:24AM -0800, Tim Kientzle wrote:
> ...
> >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.
Thank you: I managed to acquire a cold or some such thing, so nothing
between my ears is working right, and I was wondering if I'd managed
to completely lose track of reality, there.... :-}
> Since you explicitly called out the time required for the
> operation, did you have any concerns about the performance?
Probably, but the first order of business would seem to be a matter of
ensuring proper operation.
That done, I expect that NFS performmance (vs. that of tar(1)) will be a
gating factor -- but also fully expect to measure & report. :-}
> >* 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.
Excellent; thank you!
> ...
> >* 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.
Good; I have been using it for similar things rather longer than I
really want to think about. :-}
> >* Might it help to defer the compression to a point subsequent to the
> > creation of the archive proper?
>
> That should have no effect.
That's what I thought, but I'm sure you're familiar with the expression
"grasping at straws." And I'm confident that you're far mor familiar
with tar(1)'s internel workings than I ever will be. :-)
> 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.)
OK -- but that ought not be harmful, yes?
> 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.
I'll see what I can do; such details of the case that catalyzed
this thread would certainly not be appropriate for public disclosure.
I will, of course, be happy to test. :-}
Thank you very much, Tim!
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/a0c39b9f/attachment.pgp
More information about the freebsd-stable
mailing list