optimum fs param sizes (was: ZFS installs on HD with 4k physical...)

Dieter BSD dieterbsd at engineer.com
Mon Aug 22 15:31:52 UTC 2011


>> I guess formatting the filesystem for 4k sectors on a 512b drive would still
>> work but it would be suboptimal.  What would the performance penalty be in
>> reality?
>
> It would be suboptimal but only for the slight waste of space that would
> have otherwise been reclaimed if the block or fragment size remained 512
> or 2K. This waste of space is insignificant for the vast majority of
> users and there are no performance penalties, so it seems that switching
> to 4K sectors by default for all file systems would actually be a good idea.

If you have large files, then large block/frag sizes waste less space than
small ones.  Remember that keeping track of all those blocks and frags
has overhead, and that overhead can waste more space than you save at the
end of files.

Is anyone looking at extending the range of tuning variables for FFS?
Allowing even larger block/frag sizes would be useful, as well as
larger cylinder groups and fewer inodes.  Fsck runs a *lot* faster with
fewer inodes.  The expected average file size and expected average number
of files per directory limits could use work as well.

newfs -e 100000000 -b 16384 -f 2048 -g 67108864 -h 16 -i 67108864 -U
 -o space -L 58data /dev/ada9p1
density reduced from 67108864 to 3676160
/dev/ada9p1: 2861588.5MB (5860533100 sectors) block size 16384,
 fragment size 2048
        using 12754 cylinder groups of 224.38MB, 14360 blks, 64 inodes.
        with soft updates

A cylinder group size of 224.38MB is just insanely small with today's
disk and file sizes.

IIRC the block size limit is 64K, but there was some bug with using
block/frag larger than 16K/2K.  Even 64K is too small.


More information about the freebsd-hackers mailing list