:
: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.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
