From owner-freebsd-fs Wed Aug 2 13:53:47 2000 Delivered-To: freebsd-fs@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 28AD737C22D for ; Wed, 2 Aug 2000 13:53:39 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id NAA28268; Wed, 2 Aug 2000 13:52:12 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpdAAAQbaql3; Wed Aug 2 13:52:03 2000 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA06373; Wed, 2 Aug 2000 13:53:27 -0700 (MST) From: Terry Lambert Message-Id: <200008022053.NAA06373@usr06.primenet.com> Subject: Re: FFS performance for large directories? To: zzhang@cs.binghamton.edu (Zhihui Zhang) Date: Wed, 2 Aug 2000 20:53:27 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), stevec@nbci.com (Steve Carlson), freebsd-fs@FreeBSD.ORG In-Reply-To: from "Zhihui Zhang" at Jul 31, 2000 08:46:59 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > This is because the tarball is packed up in the wrong order; > > change the packing order (breadth-first vs. depth-first), > > and the "ports problem" goes away. I have done this with the > > -T option to tar, and it works fine, so long as you have an > > accurate file. This ensures that there is no cache-busting > > on the dearchive, which is the source of the problem. > > Good point. But what do you mean by saying "have an accurate file"? If you use a naked tar without -T, then it traverses the directory, depth-first. This means that it accuractely gets all of the files that are there and packs them up. If you drive it using -T, then it depends on the contents of the list-of-files file that you tell it to use. This means that you need to make sure the list-of-files file is kept up to date, or you will miss some files and/or patches and/or new ports. It's like depending on MAKEDEV instead of devfs to keep the devices up to date: if you have stale data, then you end up with a bad result that's worse than waiting around for the cache-busting creates. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message