Date: Sun, 07 Aug 2016 10:29:14 -0700 From: Kirk McKusick <mckusick@chez.mckusick.com> To: Maxim Sobolev <sobomax@freebsd.org> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: Optimizing UFS 1/2 for non-rotating / compressed storage Message-ID: <201608071729.u77HTEYF087254@chez.mckusick.com> In-Reply-To: <CAH7qZfst2pwOmec7-BRH6_gPvoMAw%2BTAjO%2BvfwuQCmy%2BTwy4wQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Maxim Sobolev <sobomax@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201608071729.u77HTEYF087254>