Fast Filesystem defaults

[Don Speck]

    In vax 4.2bsd, mkfs has an undocumented 10th parameter which
controls how many inodes to allocate.  It is given as bytes of
disk space per inode allocated.  "newfs" specifies it the same
way in its "-i" option.

(flame)
    Why does it default to the maximum inode density, one inode
per 2K of disk space?  The number of inodes could be halved and
none of the filesystems on the 9 Suns and 5 vaxen on which I can
do a "df -i" would be anywhere close to running out of inodes.
I practice what I'm preaching and still have plenty of inodes.
The extra inodes just use up space, both on disk and in the
buffer cache, they slow down "find" and "dump", and there's
more inodes to go bad (it only takes one!).

(suggestion)
    Perhaps a better default would be to allocate one inode per
filesystem block (or vice-versa).  A 4K filesystem would have
plenty of inodes.  An 8K filesystem might run out of inodes if
your average file size is small (less than 8K), but if your
files are so small, the 8K blocksize isn't a speed advantage,
and you'd probably be better off with a 4K blocksize.

    Cit-vax's primary user filesystem averages 8.5K per file,
and I screwed myself by using an 8K blocksize.	Fsck summaries
say it's badly fragmented, and I can see it's costing me in
speed, just by comparing the dump time with any 4K filesystem.

    If newfs were as ``friendly'' as the manual page claims,
it would calculate all this junk from the average file size.

			Don Speck   speck at cit-vax.arpa