the 10% factor

[Dave Hitz]

In article <21436 at adm.BRL.MIL> MATHRICH at umcvmb.missouri.edu (Rich Winkel UMC Math Department) writes:
> I understand that allowing bsd filesystems to exceed 90% of their
> capacity results in a significant reduction in performance.  This makes
> a certain amount of sense to me, at least when files are being created,
> deleted or appended to.  However, I've been told this is also true of
> static filesystems.  For instance, if I have a 20MB partition set aside
> for an nfs client's swap activity, I can't utilize the entire 20MB for
> the swap file, I'm supposed to leave 10% unused to avoid a performance
> impact, eve though the swap file's size is unchanging.  Is this true?
> Could someone explain this to me?

Here's a shot.

The problem is that as a file grows on a mostly full partition, the
block immediately following the last one in the file is generally not
available.  Even on almost empty files this is always a possibility,
but statistically it turns out that only as the filesystem passes 90%
full does this problem become nasty.

Once blocks for a file are allocated in a bad order, it doesn't matter
if the filesystem is static or not.  If you read that file
sequentially, the disk will have to seek all over the place to get the
blocks.  So even for static filesystems, some limit probably still
makes sense.  (You might try creating known rarely used files last, and
crank up utilization to 100%.)

Now the question about swap is interesting.  When you create a swap
file using mkfile(8), it allocates disk blocks when the file is
created.  If you create a 20 MB swap file in an otherwise empty 20 MB
partition, the block allocation would probably be quite good because
there would be no conflict with smaller chuncks of space being
allocated in other files.  If you want more than one swap file per partition,
that would probably work also, but make sure *not* to run the mkswap's in
parallel.  Do them one after the other.  (And don't use the -n option which
would defeat the whole point of getting the blocks nicely allocated at
create time.)

-- 
Dave Hitz					home: 408-739-7116
UUCP: {uunet,mips,sun,bridge2}!auspex!hitz 	work: 408-492-0900