Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: thorstad@wooglin.scc.com (Brian Thorstad)
Newsgroups: comp.sys.sun
Subject: Re: minfree for large file systems
Message-ID: <8812202223.AA01004@wooglin.scc.com>
Date: 6 Jan 89 22:38:02 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 28
Approved: Sun-Spots@rice.edu
Original-Date: Tue, 20 Dec 88 17:23:41 EST
X-Sun-Spots-Digest: Volume 7, Issue 90, message 2 of 9

While I do not know the "finer intricacies of the BSD file system", I have
pondered the same issue of not having 10% of the disk available for
general use.

I am pulling this directly from the grey matter, so please don't yell if
there is an excellent discussion of this in one of the many manuals shiped
in the doc-u-crate.

1)  While not perfect, there is an algorithm used by Sun (BSD too?) to
minimize the distance seeked for newly allocated blocks to an existing
file (fragmentation is a given).  The "closer" it is, the faster.  Each
file system is logically divided into multiple "cylinder groups".  When a
new block is needed, there is an attempt to allocate space from the same
cylinder group as the previous block.  This is an attempt only, and does
improve effeciency.  The problem is that it works best if you can afford
to have a liberal amount of free disk space scattered around.

Cylinder groups are a logical concept that only exist within the block
allocation routines, and should not be confused with file systems and
other concrete things.

2)  While I do not recommend it, you can configure a file system with less
than 10% free space (or more).  Check the details of the mkfs(8) command.
Less space would probably be appropriate for a file system that is static
once created (e.g. /usr on OS 4.0)

Brian Thorstad
(thorstad@wooglin.scc.com)