Path: utzoo!mnetor!uunet!husc6!think!bloom-beacon!oberon!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (Don Speck)
Newsgroups: comp.unix.wizards
Subject: Re: Compressing unix disks
Message-ID: <5949@cit-vax.Caltech.Edu>
Date: 26 Mar 88 06:43:00 GMT
References: <1071@ndmath.UUCP> <2452@umd5.umd.edu> <305@marconi.SW.MCC.COM> <1097@hubcap.UUCP> <208@hotlr.ATT>
Organization: California Institute of Technology
Lines: 54
Summary: fragmentation

In article <4336@pwcs.StPaul.GOV>, daveg@pwcs.StPaul.GOV (Dave Glowacki) writes:
>				   My boss maintains that 10% of the
> AVAILABLE blocks must be kept free, leaving us with only about 81% of the
> total disk space.  I think that the system's already got the space it needs.

What counts is the percentage of whole blocks that are free.  Minfree
is one way of attaining this percentage.  If you're able to maintain
free space by other means, you can reduce it (our facilities manager
enforces enough free space that I set minfree to 5% on our user disks).

In article <2452@umd5.umd.edu>, chris@trantor.umd.edu (Chris Torek) suggests:
>	tunefs -m 0 /u

However, this is too far.  If you have any small files, some of the free
space will be in the form of fragments.  If all that's left is fragments,
you can't create a file larger than the largest free fragment.	When this
happens, the disk should be declared full, so that file truncations due to
insufficient space will be obvious enough (empty files) that neither humans
nor programs (such as sendbatch) will be tempted to use the trashed files.
(There oughta be an option...)	It's also wise to reserve a few whole
blocks for critical operations like updating /etc/passwd (ouch!).

Fragments are reassembled into whole blocks only when all the fragments
of the block are free at the same time.  This sets a lower bound on
average free space.  If you maintain less, fragments will accumulate
and force more unusable free space until adjoining files are deleted.
The more file tails that fit in a block, the less likely that all will
be free at once.  If the median file size is less than 1/3 of a block,
you can expect several percent of the space to be lost to fragmentation.
The median file size can be increased some by raising the fragment size,
but that wastes more space than the fragmentation, so instead you should
decrease the blocksize.

Usenet articles are usually the worst, causing about 3% fragmentation
(assuming a 4K blocksize).  Filesystems with mostly static files do a
lot better (our /usr/src has 1% minfree).

Beyond this bare minimum of free space, you'd like to have enough free
that a rotationally optimum block is usually available.  The more tracks
per cylinder, the more rotationally optimum blocks there are to choose
from (thus disks with many heads may be able to run a little more full).
If the disk has nonzero head-switch delay (RA81), there is only one
rotationally optimum block, i.e. staying on the same track (done with
negative rotdelay), so on those you might want to leave more free space.
Ditto for contiguous allocation (done with tunefs -a and special drivers).

If you're squeezed for space, you should look first at the number of
inodes allocated.  It's not unusual to be able to reclaim 4% of the
total space that way.

(I wonder how a free space reserve affects SysV, Counterpoint & Masscomp
filesystems)?

Don Speck   speck@vlsi.caltech.edu  {amdahl,ames!elroy}!cit-vax!speck