Date: Wed, 22 Dec 1999 23:53:23 -0600 (CST) From: Ryan Thompson <freebsd@sasknow.com> To: Mark Newton <newton@internode.com.au> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Default minfree performance restrictions? Message-ID: <Pine.BSF.4.10.9912222302240.50821-100000@sasknow.com> In-Reply-To: <19991223131531.C17257@internode.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Mark, Thanks for the reply. On Thu, 23 Dec 1999, Mark Newton wrote: > On Wed, Dec 22, 1999 at 07:25:39PM -0600, Ryan Thompson wrote: > > The idea has merit, but you might need to increase the size of your > cylinder groups to compensate if you lower the MINFREE threshhold which > invokes space optimization. If UFS cylinder groups are too full the > filesystem starts to find it difficult to find free blocks which are > "geographically" close to the region of the disk inhabited by a file > you're appending to, which reduces perforance. As such, you should > build a filesystem with, perhaps, newfs -c32 (or whatever) before > lowering the threshhold. Yup yup... I just tried -c 48 (see below). I took the plunge. Having to do a newfs ANYWAY, as I allocated a 13GB slice solely to my purpose, here, I set it up with 16K blocks, 48 c/g and 2048K frags. (The latter was required to go with 16K blocks). On a sidenote, I tried to specify a minfree of 6% in newfs (before turning the minimum down in the kernel source): Warning: changing optimization to space because minfree is less than 8% Nice, but somewhat annoying :-) I just gave it 8% at that point and used tunefs to set it down to 3% after newfs completed. Before mounting my 13GB guinea-pig, I reduced the minimum threshold from 5% to 1% in ffs_alloc.c (so, lowest minfree setting is 2%, without opt being changed to space..).. Funny, though, as I took more time to read over the code, it looks like that value is actually only enforced if the optimization is ALREADY set to space, presumably because the fragmentation is too high, or as a result of having newfs set it to space FOR you, then not bother to change it to time. Anyways, I rebuilt my kernel with the changed values and rebooted/mounted new partition. I'm in the process of running some tests (for starters: just copying/moving/deleting (in parallel :-) a few gigs' worth of small files at a time... I think I'll try symlinking /usr/src and /usr/obj to the new partition and try a buildworld while this is going on) All the while, keeping an eye on my frag level, and the odd dumpfs...) So far everything appears to be working quickly and efficiently. Despite what I've thrown at it so far, the frag level continues to be very low (0.1% at 25% capacity. All of this is FAR more punishment than most of my filesystems normally take. I know... This is all pretty subjective right now. Once this new fs gets past the preliminary stages, though, I'll try for some more quantitative results :-) As was expected, I DID recover nearly a gig of space :-) > > Or... Maybe most of the more knowledgeable individuals who follow this > > list are just gone for the holidays. > > Seriously, though, folks, does my idea make any sense at all? > > I'm sure if you send-pr a patch which turns the threshhold into a > sysctl variable which defaults to 5 you might end up with some careful > consideration being given to the idea... Hmmm... I might just do that once I get some more quantitative results on at least one system. Once I'm sold on the idea, it'll be easier to get motivated enough to do the patch. I'd hate to do it, submit it, then realize what a waste of time it was :-) -- Ryan Thompson <ryan@sasknow.com> 50% Owner, Technical and Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9912222302240.50821-100000>