Alan's answer is complete for my original questions about this message in
our logs:
Jun 8 10:16:28 a1 vmunix: /disk2: optimization changed from TIME to SPACE
Jun 10 21:32:12 a1 vmunix: /disk2: optimization changed from SPACE to TIME
Thanks to all who replied so fast!
---------- Forwarded message ----------
Date: Mon, 11 Jun 101 12:21:11 -0600
From: alan_at_nabeth.cxo.dec.com
To: Edward D. Silver <eds_at_avweb.com>
Subject: Re: Time and Space?
The UNIX File System, an implementation of the Berkeley
Fast File System, offers two choices for how to optimize
space allocations for small files. Under very particular
circumstances (that I've never quite completely figured
out even looking at modern sources), it will switch from
one to the other and back. While you can pick one or the
other when the file system is created or change it with
tunefs(8), it will still switch as necessary.
The two choices are "time" or "space". When space for a
small file or the end of a medium sized file is allocated
(smaller than the file system block size) a fragment is
allocated to the space. You can either allocate a new
file system block for the fragment on the assumption that
the portion of the file will grow and the remainder of
the block can be used for that growth. This is time
optimization since the fragments won't have to be copied
around when the space is extended.
The disadvantage of this choice is that fragments basically
use up whole blocks. The point of having fragments is that
they can be combined into single blocks and not waste as
much space. Packing fragments into as few blocks as needed
is space optimization.
I'd suppose that the automatic switch-over is based on
having to decide between "change the optimization" or
not extend the file. I'd guess that extending a file
will always win. When sufficient space is freed up,
it can switch back.
Received on Mon Jun 11 2001 - 18:21:21 NZST