tunefs

[Jim Prescott]

In <EMV.90Aug31155848 at stag.math.lsa.umich.edu> emv at math.lsa.umich.edu (Edward Vielmetti) writes:
>In some other article someone said:
>>This changes the minimum amount of free space from the default (10
>>percent) to a more adequate [in a disk-space-starved environment, like
>>ours :-(] 2% (that's the number 2 in the /tunefs commands).
>
>What does the space-performance tradeoff curve look like?
>Ideally I want to get enough disk space back so that people will notice
>that there's more, without having them notice that it's any slower.

Who doesn't ?-)

One thing to be aware of if you lower minfree is that you increase the
chances of running out of disk space while you still have space left (ie.
getting a "no space on device" message while df still shows available
disk space).

This happens because the FFS keeps track of 2 types of free space, full
blocks and fragments (often 8k/1k).  When looking for space the system
will split a free block into fragments but it won't coalesce fragments
into a full block (naturally it will coalesce them when free'ing
stuff).  If you run out of full blocks then the disk is full for most
purposes, even if df shows 20M free.

This can occur even if you don't change minfree but would be extremely
unlikely.  The problem occurs when more than minfree% of your disk is
free fragments which would require almost pathological fs activity for
10% but gets more likely at 1 or 2%.

Changing optimization to space will also make running out of full blocks
less likely.  SunOS 4 does this automatically when the actual minfree
drops but this is usually too late (the fragmentation build up over time).

Note that I think it was with SunOS 3.5 that we actually observed this
but I doubt anyone with a reasonably stock FFS does frag->block coalescing
on demand.  It would be real hard/slow.

On suns you can use dumpfs to get info on how your free space is
distributed (nbfree and nffree).  (use a pager with dumpfs as it prints
out tons of stuff, the most useful of which is in the first page).
-- 
Jim Prescott	jgp at moscom.com	{rutgers,ames}!rochester!ur-valhalla!moscom!jgp