> :In message <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
