From owner-freebsd-stable@FreeBSD.ORG Wed Nov 26 19:04:14 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BF801065674; Wed, 26 Nov 2008 19:04:14 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7EA8FC0C; Wed, 26 Nov 2008 19:04:13 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id mAQJ4DE3060067; Wed, 26 Nov 2008 11:04:13 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id mAQJ4DE0060066; Wed, 26 Nov 2008 11:04:13 -0800 (PST) (envelope-from david) Date: Wed, 26 Nov 2008 11:04:13 -0800 From: David Wolfskill To: Tim Kientzle Message-ID: <20081126190413.GF83287@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Tim Kientzle , stable@freebsd.org References: <20081126021551.GA83287@bunrab.catwhisker.org> <492D9A34.6020509@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xXF8SilVSrRwayWj" Content-Disposition: inline In-Reply-To: <492D9A34.6020509@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org Subject: Re: bsdtar vs. NFS: Couldn't visit directory: No such file or directory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2008 19:04:15 -0000 --xXF8SilVSrRwayWj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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.) >=20 > 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. >=20 > 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? >=20 > 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? >=20 > 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 --=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. --xXF8SilVSrRwayWj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkktnawACgkQmprOCmdXAD3GuwCdFFnsS3f1EB7qGJpaNLO1SSoS 2fwAoIK72AbdHOAO4tkpCYhVLXQVUo1Z =ugYe -----END PGP SIGNATURE----- --xXF8SilVSrRwayWj--