>> 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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
