Optimizing UFS 1/2 for non-rotating / compressed storage

Kirk McKusick mckusick at chez.mckusick.com
Sun Aug 7 17:29:16 UTC 2016


> From: Maxim Sobolev <sobomax at freebsd.org>
> Date: Sun, 7 Aug 2016 01:09:41 -0700
> Subject: Re: Optimizing UFS 1/2 for non-rotating / compressed storage
> To: Kirk McKusick <mckusick at mckusick.com>
> 
> Thanks, Kirk,
> 
> So far, we've been set the following, which seems to pessimize compression
> levels slightly but greatly reduce size of incremental upgrade using rsync
> after we change just few files and re-pack:
> 
> newfs -n -b 65536 -f $((65536 / 2)) -m 0 -L "${FW_LABEL}" "/dev/${MD_UNIT}"
> 
> Unfortunately 64k is the max block size we can get out of it (128k is
> rejected) and we run out of inodes if we set fragment size to be 64k as
> well. Is there a fundamental limitation on the size of the block? I am
> curious to see how 128/32 might work considering that bigger block size is
> preferred by the compressor. We'll try to play with other options too, as
> you've suggested.
> 
> -Max

You can get more inodes by using the -i option to newfs. If you use
-i $((65536 / 2)) you should then be able to set the fragment size
to the block size.

The limit on the block size is set by the kernel. It is not an inherent
limitation of the filesystem. If you want to try 128K blocksize, just
bump up MAXBSIZE in /sys/sys/param.h to 128k and buildworld. Note that
MAXBSIZE cannot exceed MAXPHYS which is currently 128k. I would not
recommend trying to push MAXPHYS bigger as that affects a *lot* of the
underlying I/O amd VM subsystems.

	Kirk McKusick


More information about the freebsd-fs mailing list