Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: mangler@csvax.caltech.edu (Don Speck)
Newsgroups: comp.sys.sun
Subject: Re: minfree for large file systems raises question
Message-ID: <8901110832.AA13182@csvax.caltech.edu>
Date: 14 Jan 89 05:27:49 GMT
Sender: usenet@rice.edu
Organization: Interleaf Inc, Cambridge, MA
Lines: 25
Approved: Sun-Spots@rice.edu
Original-Date: Wed, 11 Jan 89 00:32:43 PST
X-Sun-Spots-Digest: Volume 7, Issue 103, message 9 of 11

The "minfree" parameter is necessary to provide a free space pool for
fragment coalescing.

Never set the minfree so low that you run out of free whole blocks before
"df" says it's full.  You'll think you have space, but won't.

The smaller the ratio of average (median?) filesize to blocksize, the
larger the minfree needs to be.  If you must use an 8K/1K filesystem for
netnews (average filesize of 2.5K), minfree should be large, 15-20%.
Filesystems containing mostly large files can use a small minfree, since
large files allocate only whole blocks.

Files created when the disk isn't very full, which are not changed when
the disk is near full, do not contribute to rising fragmentation.  Fsck
reports the amount of free space that occurs as fragments.

The above considerations dictate that minfree has to be at least 3-5% for
typical user filesystems.  To maintain speed of sequential transfers, you
want enough additional space that a free block can usually be located on
the same cylinder, in a rotationally optimal position.  (The latter can
only matter if you set rotdelay correctly).  Rotational optimization is a
moot point on typical servers, which are seeking between partitions all
the time anyway, except during backups and I/O benchmarks.

Inodes are another place one can often economize on space.