mr@uunet.uu.net (12/21/88)
I am pondering whether the "minfree" default of 10% makes sense with the
very large file systems that we are beginning to see (1Gb+). OK, so disk
is cheaper per megabyte than ever it was, but are we wasting
bucks/pounds/francs/ningies/etc. needlessly?
Would anyone who understands the finer intricacies of the BSD file system
like to comment or suggest, please. Would 5% start to make more sense? Am
I talking alone in my wonder?
Martin Reed, Racal Imaging Systems Ltd
uucp: mr@ritd.co.uk,uunet!ukc!ritd!mr,sunuk!brains!mr
Global String: +44 252 622144
Paper: 309 Fleet Road, Fleet, Hants, England, GU13 8BUthorstad@wooglin.scc.com (Brian Thorstad) (01/07/89)
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)