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 [EMAIL PROTECTED] Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpq52cT0uPej.pgp
Description: PGP signature
