speck@cit-vlsi (Don Speck) (08/10/85)
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.arpachris@umcp-cs.UUCP (Chris Torek) (08/11/85)
> If newfs were as ``friendly'' as the manual page claims, >it would calculate all this junk from the average file size. One question: where is it going to *get* the average file size? (Specifying it with an option makes it essentially the same as -i.) In general, one inode per 2K is way too much (try one per 4K for a default), but you are a *lot* better off with too many inodes than too few. And (believe it or not) I managed to run out at one/2K---I put /usr/spool/news on its own RK07 over at eneevax, and it ran out of inodes. I remade the file system with one inode per 1K data.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
smb@ulysses.UUCP (Steven Bellovin) (08/11/85)
On rp07s, it's quite easy to run out of i-nodes; there are *many* blocks per cylinder group, and 2K i-nodes just doesn't make it. We have to override the cylinder group size on our rp07s just to get enough i-nodes.
chris@umcp-cs.UUCP (Chris Torek) (08/12/85)
>On rp07s, it's quite easy to run out of i-nodes; there are *many* blocks per >cylinder group, and 2K i-nodes just doesn't make it. We have to override >the cylinder group size on our rp07s just to get enough i-nodes. I don't quite understand.... From man 8 newfs: .B \-i number of bytes per inode This specifies the density of inodes in the file system. The default is to create an inode for each 2048 bytes of data space. If fewer inodes are desired, a larger number should be used; to create more inodes a smaller number should be given. If you have one inode per 2K of data space, then it doesn't matter how many blocks/cyl-group; more blocks just means more inodes. So how does having rp07s make any difference? -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
mangler@cit-vax (System Mangler) (08/12/85)
> If you have one inode per 2K of data space, then it doesn't matter > how many blocks/cyl-group; more blocks just means more inodes. So > how does having rp07s make any difference? Mkfs cannot allocate more than MAXIPG (=2048) inodes per cylinder group. With 16 cylinders per group, this limit comes into play on any drive with more than 512 sectors per cylinder. RM05 19 x 32 = 608 effective -i value = 2432 RA81 14 x 51 = 714 effective -i value = 2856 Eagle 20 x 48 = 960 effective -i value = 3840 2298 16 x 68 = 1088 effective -i value = 4352 9775 40 x 32 = 1280 effective -i value = 5120 9771 16 x 84 = 1344 effective -i value = 5376 RP07 50 x 32 = 1600 effective -i value = 6400 Thus on a big disk, you have to decrease the number of cylinder groups if you need lots of inodes. Mkfs doesn't tell you this, though. So you see that the newfs default for "-i" is usually not only unrealistic, but a false promise as well. For the disks most people use (Eagle or RA81), -i 4096 is a more truthful value. My point was that newfs, which is supposedly a ``friendly'' preprocessor for mkfs's long argument list, ought to compute things like -i, -b, -f, -c, and maybe -m from a single novice- understandable number, the expected average file size. Anyone can divide the numbers from "df -i" output, or from a count of files and megabytes on a distribution tape. And isn't this the figure that really determines what settings are optimal? Don Speck speck@cit-vax.arpa
smb@ulysses.UUCP (Steven Bellovin) (08/12/85)
> >On rp07s, it's quite easy to run out of i-nodes; there are *many* blocks per > >cylinder group, and 2K i-nodes just doesn't make it. We have to override > >the cylinder group size on our rp07s just to get enough i-nodes. > > I don't quite understand.... From man 8 newfs: > > .B \-i number of bytes per inode > This specifies the density of inodes in the file system. > The default is to create an inode for each 2048 bytes of data space. > If fewer inodes are desired, a larger number should be used; > to create more inodes a smaller number should be given. > > If you have one inode per 2K of data space, then it doesn't matter > how many blocks/cyl-group; more blocks just means more inodes. So > how does having rp07s make any difference? Sorry, I wasn't explicit enough. There is a hard limit (MAXIPG) on the number of inodes per cylinder group; on rp07s, the default cylinder group is so large that newfs (I believe) *silently* cuts back on the i-node density, in order to stay within this limit.