tunefs question

[Rick C. Petty]

On Thu, Jun 07, 2007 at 05:04:09PM +0200, Richard Noorlandt wrote:
> 
> While reading a bit about tunefs I noticed that UFS reserves 8% of the drive
> space for the root user and the system. However, I don't really understand
> what this space is actually used for. From the tunefs man page I understand
> that it is primarily used to guard against fragmentation, and that's about
> it. Is this the only thing that the reserved space is used for?

It's used as the point where the filesystem changes over from a
time-efficient algorithm to a space-efficient one.  If you don't believe
there's much of a difference, try writing past 100% full and witness the
performance hit.  There is probably a good reason why the default is 8%..
you could tune that down, but I'd be wary of doing so.

> I'm building a large array for my fileserver, and it actually hurts a bit to
> see that so much space is "wasted" without a very clear reason to do so.

If you want to talk about wasted space, look at how many inodes are
allocated on a newfs and how many you actually end up using.  I have a
patch to newfs which reports the amount of space "wasted" in metadata
blocks..  Reducing the number of cylinder groups and number of inode blocks
allocated per cylinder group can make this "wasted" space drop from 3% to
0.3%, in some circumstances.

> Especially because the data on the array won't be modified very often, it
> appears to be quite a lot of disk space just to prevent fragmentation. Does
> anybody have some more information on this?

If you don't care about fragmentation or speed, go ahead and fill up past
100%.  If you need non-root writable access, go ahead and tune the 8% to a
smaller number.  Be warned-- you will likely be sacrificing speed just to
fill that extra space.  If your modifications are rare, you might be able
to run some sort of offline defragmentation program.  I was working on such
a program at one point.

Also, I wouldn't call this "a lot of disk space".  Disks are cheap:

http://www.newegg.com/Product/Product.asp?Item=N82E16822136073

$115 for 500GB drives.  If you need more space, buy more disks.  You may
wish to consider the opportunity cost of the time you spend tweaking file
systems to use that extra couple percent space versus the cost of
additional storage.

> And while I'm at it: what is the effect of the expected average file size
> option? What are the benefits and dangers of tweaking it? From the FreeBSD
> handbook I understand that the FS actually optimizes itself as time passes,
> but that's about all that's said about it.

Don't tweak average file size (or it's related avg. files per directory
setting)!  There are some reported bugs in UFS regarding the computation
(integer overflow) that is performed on the average file size parameter.
I first noticed this when tweaking it on a new filesystem that I knew the
average filesize was high (ISO images) and my kernel panicked on the first
write attempt.  Subsequent reboots panicked during fsck.  I've looked
into patching the necessary UFS code but never got around to a complete
fix.

Instead, just modify the inode density (-i option to newfs) which means
pretty much the same thing and doesn't have the bug.  Tweaking this
parameter only affects newfs..  actually it's used in the computation for
number of inodes per cylinder group and indirectly affects total number of
cylinder groups-- newfs uses a loop to increase number of cyl groups until
the free block bitmap can fit into a single filesystem block (which
defaults to 16384 bytes).  Tweaking this option, I've been able to reduce
the space allocated to metadata by tenfold.

I recommend first running newfs with the -N option to print out the total
number of allocated inodes.  Make sure you won't go over this number
(running out of inodes can be an aggravating problem), and if you're
satisfied rerun newfs for real.  If you're tweaking -i, you may wish to
tweak the block size as well..  but make sure the fragment size is
precisely 1/8 of the block size or all bets go out the window
(particularly: performance hits).  Aside from those three settings, I don't
mess with newfs much because there is little to gain.

If you know the precise files (i.e. total number of files + number of
directories --> number of inodes, average filesize --> inode density), this
helps you speeze more space without sacrificing anything.  I do this often
when transitioning a read-write filesystem to a read-only / archive
filesystem.  Set the time/space setting to space, set the reserved free
space from 8% to 1%, fill up the filesystem, unmount and set it back to
time & 8%, and mount it read-only for the remainder of its lifetime.  This
requires a total of five extra minutes of your admin time.

Good luck,

-- Rick C. Petty