Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!speck@cit-vlsi From: speck@cit-vlsi (Don Speck) Newsgroups: net.unix-wizards Subject: Fast Filesystem defaults Message-ID: <597@brl-tgr.ARPA> Date: Sat, 10-Aug-85 11:43:32 EDT Article-I.D.: brl-tgr.597 Posted: Sat Aug 10 11:43:32 1985 Date-Received: Mon, 12-Aug-85 08:26:03 EDT Sender: news@brl-tgr.ARPA Lines: 33 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@cit-vax.arpa