forcing a permanent "time" optimization with tunefs ?

[Stefan Esser]

Juri Mianovich wrote:
> tunefs: should optimize for space with minfree < 8%
>
> but the time optimization setting will stick, as long
> as you have at least 6% minfree.  This is documented
> in the tunefs man page, in fact.
>
> The answer to my original question "can I force time
> optimization if I am below 6%" appears to be "no".
> You can successfully set optimization to time, but the
> kernel will always (almost immediately) switch it back
> to space optimization.

Have you ever read the (now ancient) paper about FFS?

The file-system needs free space to avoid fragmentation
(not the one reported by fsck), which would slow down
large file access by several orders of magnitude. So
you pay a high price for using up those last few percent
of capacity (except in special usage cases).

You can easily achieve the effect of always optimizing
for time if you create your file system with identical
block and fragment sizes. (I'm wondering, whether you
know, what optimization for time or space is about???)

Optimization for time causes file ends to be stored in
full blocks (leaving the rest of the block unused). All,
the optimization for space does, is put several files
smaller than one block (or file ends) into one block
(e.g. if you have got 16KB blocks and 2KB fragments
then 2KB + 4KB + 20KB could be put into two 16KB blocks,
while optimization for time would require 4 blocks of
16KB to store those same files).

In fact, optimization for space allows to fill up all
the (previously only partly allocated) blocks for use
by small files. And if you start too late to do this,
you'll have too many blocks used only to a fraction.

Back to the example: If you have only 4 blocks of 16KB,
then storing 2KB, 4KB, 20KB will use up those blocks,
if you are optimizing for time:

F1:
Block 1: 2KB (14KB left free)

F2:
Block 2: 4KB (12KB left free)

F3:
Block 3: 16KB (full block)
Block 4: 4KB (12KB left free)

In that case, your disk was full and no more data
could be written. If you had switched to optimize for
space early (the correct time to switch modes does
not so much depend on a percentage of free space, but
rather on the ratio of partial blocks to full blocks
and to free blocks), this could have all been stored
in 2 blocks, leaving half of your space available:

F1 + F2 + F3(tail)
Block 1: 2KB // 4KB // 4KB (6KB left)

F3:
Block 2: 16KB (full block)

Block 3: (16KB free)
Block 4: (16KB free)

So if you are willing to waste space for small files
(or if you do not expect to store many small files,
since the optimization is only used for files that
do not require indirect blocks), then create your
file system with fragment size equal to block size
and waste some space. But I thought you wanted to
put as much data on your disk and did not want to
waste space? Well, then better let those well thought
out optimizations (TM) do their job and do not step
in their way ;-)

You never mentioned what you are trying to achieve.

Their are cases, where a very low min-free man make
sense (static file systems consisting of files that
are larger than some 200KB). In all other cases you
are going to be hurt.

All this (and much more) is explained in much detail
in the FFS paper by McKusick et.al., see:

    /usr/share/doc/smm/05.fastfs/paper.ascii.gz

Regards, STefan