From owner-freebsd-arch Fri Mar 16 17:26:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from thehousleys.net (frenchknot.ne.mediaone.net [24.147.224.201]) by hub.freebsd.org (Postfix) with ESMTP id A178637B718 for ; Fri, 16 Mar 2001 17:26:23 -0800 (PST) (envelope-from jim@thehousleys.net) Received: (from root@localhost) by thehousleys.net (8.11.3/8.11.2) id f2H1QLY02633; Fri, 16 Mar 2001 20:26:21 -0500 (EST) (envelope-from jim@thehousleys.net) Received: from thehousleys.net (baby.int.thehousleys.net [192.168.0.24]) by thehousleys.net (8.11.3/8.11.3) with ESMTP id f2H1QJf02625; Fri, 16 Mar 2001 20:26:19 -0500 (EST) (envelope-from jim@thehousleys.net) Message-ID: <3AB2BD3B.7E65D416@thehousleys.net> Date: Fri, 16 Mar 2001 20:26:19 -0500 From: James Housley X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dima Dorfman Cc: freebsd-arch@freebsd.org Subject: Re: Inherate nodump cause significant slow down of dump References: <20010317011847.EA9083E1E@bazooka.unixfreak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dima Dorfman wrote: > > James Housley writes: > > The changes to src/sbin/dump/traverse.c (1.10.2.2) cause significant > > slow down of the dump estimate phase. Specifically Phase II. My /usr > > partition has about 2.5G of data including ports. I had just the > > /usr/ports director flagged as nodump. I think that this needs to be > > backed out, or fixed before the 4.3-RELEASE. > > I'm not terribly opposed to this, but OTOH I don't see why it's > necessary. The slowdown only occurs if you set nodump on a directory. > With the old behavior, this wouldn't do anything useful (AFAIK), so if > you have nodump on a directory, you probably expect the new behavior. > The latter has a problem with taking more time than it should (I think > it actually takes the same amount of time as dumping everything under > the nodump'd directory would). In other words, the only thing that's > broken is the new feature. > I haven't tested this yet, but should be able to tomorrow. But I believe that if I do chflags -R nodump /usr/ports it will not a significant more amount of time to process, throught Phase II, then with out the nodump flags under the old version. I am also guessing the with the new version chflags -R nodump /usr/ports will be about the same amount of time as with the old code. I am not opposed to the feature. Acutally I was suprised that that is not the way it worked when I first found the flag. However, there has to be a better way to implement it. BTW it breaks amanda's dump estimates. Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ ----------------------------------------------------------------- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net --------------------------------------------------------------------- microsoft: "where do you want to go today?" linux: "where do you want to go tomorrow?" BSD: "are you guys coming, or what?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message