Date: Sat, 9 Dec 2000 08:16:39 -0600 (CST) From: Joe Greco <jgreco@ns.sol.net> To: hackers@freebsd.org Cc: dillon@earth.backplane.com, phk@critter.freebsd.dk Subject: Re: Optimal UFS parameters Message-ID: <200012091416.IAA61771@aurora.sol.net> In-Reply-To: <200012090354.VAA15571@earth.execpc.com> from "jgreco@execpc.com" at Dec 08, 2000 09:54:53 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> :In message <200012070821.eB78LeQ07926@earth.backplane.com> Matt Dillon writes: > :: : -b 16384 -f 4096 -c 159 > :: I think Bruce swears by 4K (page-sized) fragments. Not a bad > :: way to go. I use 2K because I (and others) put in so much hard work > :: to fix all the little niggling bugs in the VM system related to partial > :: page validation and, damn it, I intend to use those features! > : > :At the other end of the spectrum, 32M [sic] and 64M [sic] disks work > :well with > : -b 4096 -f 512 -c 10 > : > :But I tend to do what phk has done with the large -c flags on my > :insanely-sized, rediculously-cheap XXG IDE drives. > : > :Warner > > Well, too-large a C/G will result in greater file fragmentation, > because FFS can't manage the file layouts in the cylinder groups > as well. The default of 16 is definitely too little. 100+ is probably > too much. Something in the middle will be about right. > > The fragmentation value returned by fsck would be an interesting number > to publish. 'fsck -n /dev/...' on an idle fs (you don't have to unmount > it). Anything over 3% fragmentation is a problem. Something like > /usr will typically be in the 1-3% range. A large partition that is > still half empty should be in the 0.0-0.5% range. > > A combination of a larger C/G (meaning fewer groups on the disk) > and fewer inodes (a higher -i value) will dramatically decrease fsck > times. After a certain point, though, continuing to increase C/G will not > effect the fsck times. So. Previously, FreeBSD had various issues with larger block and fragment sizes - I think Matt was the guy who told me this. A larger B/F size also allows a larger C/G, so I'm wondering if this is still true (both for FreeBSD 3.5 stable and 4.2 stable). Comments? -- ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 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?200012091416.IAA61771>