This is *real* late. Sorry.
Original question (paraphrasing/summarizing):
The 'tunefs' command has an option "optimize", but the man page
for 'tunefs' doesn't even mention this option. What does it do?
At the time it seemed counterintuitive that UNIX could do anything to make
disk files use less space, or to trade space for time. This was partly
right, but ignored fragment management.
Best answer came from auspex!guy@uunet.UU.NET (Guy Harris) who quoted me
a piece of the BSD 4.3-tahoe "ufs_alloc.c", which explained what UNIX
was really doing, and also enclosed an excerpt of the BSD 4.3-tahoe man
page for tunefs(8), which DOES explain the optimization option quite well.
[from BSD 4.3-tahoe ufs_alloc.c ...]
switch ((int)fs->fs_optim) {
case FS_OPTSPACE:
/*
* Allocate an exact sized fragment. Although this makes
* best use of space, we will waste time relocating it if
* the file continues to grow. If the fragmentation is
* less than half of the minimum free reserve, we choose
* to begin optimizing for time.
*/
...
case FS_OPTTIME:
/*
* At this point we have discovered a file that is trying
* to grow a small fragment to a larger fragment. To save
* time, we allocate a full sized block, then free the
* unused portion. If the file continues to grow, the
* `fragextend' call above will be able to grow it in place
* without further copying. If aberrant programs cause
* disk fragmentation to grow within 2% of the free reserve,
* we choose to begin optimizing for space.
*/
[from BSD 4.3-tahoe TUNEFS(8) ...]
-o optimization preference
The file system can either try to minimize the time spent
allocating blocks, or it can attempt minimize the space
fragmentation on the disk.
If the value of minfree (see above) is less than 10%,
then the file system should optimize for space to avoid
running out of full sized blocks.
For values of minfree greater than or equal to 10%,
fragmentation is unlikely to be problematical, and
the file system can be optimized for time.
Thanks to the many others who responded, even the ones who simply told
me which FM to R. :)
kevins@Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
proton!baumann@ucrmath.ucr.edu (Michael Baumann)
jaffa@cs.tut.fi (Salo Jari)
Calum Mackay <calum.mackay@mrc-applied-psychology.cambridge.ac.uk>
Roy Smith <roy@alanine.phri.nyu.edu>
Emmett Hogan <hogan@csl.sri.com>
ddull@Rational.COM (David Dull)
flp@tcs.com (Rick Preston)
kwthomas@nsslsun.gcn.uoknor.edu (Kevin W. Thomas)
Steve Hanson <hanson@calvin.fnal.gov>
bb@math.ufl.edu
odt@base.bellcore.com
Mike Maciolek mikem@juliet.ll.mit.edu (617) 981-3174
Network Engineer --- MIT Lincoln Laboratory Group 43 --- Weather Sensing
"I don't want the whole world; I just want your half."
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:18 CDT