mangler@cit-vax.Caltech.Edu (Don Speck) (04/09/89)
In article <28454@apple.Apple.COM>, fair@Apple.COM (Erik E. Fair) writes: > In the referenced article, mangler@cit-vax.Caltech.Edu (Don Speck) writes: > > By the way, will someone please put the ilist into a file, so > it can be dynamically extended? > > If you do that, how do you propose to allocate it, such that you don't > have to go seeking all over the disk to find the inode you're looking > for? A file containing all the inodes would probably need only one indirect block on a BSD or V9 filesystem. That indirect block is likely to remain in the buffer cache. The kernel itod() macro would be replaced by a lookup in an indirect block. For large files such as this, the BSD filesystem allocates 256K from each cylinder group before switching to the next. That's 2048 inodes allocated from each cylinder group, same as mkfs allocates now. BSD programs that read inodes sequentially generally do it one filesystem block at a time. Having inode blocks rotationally placed instead of contiguous would speed up such sequential reading. Having it in a file means that utility programs also get the benefit of readahead. The kernel likewise reads (and caches) inodes a block at a time, hence is not taking advantage of the current contiguous allocation of inodes. ialloc() would want to allocate related files to the same inode block (BSD ialloc halfway does this now) and scan the indirect block of the file-of-inodes when it needed another inode block, looking for block pointers near the desired value. Granted, the file-of-inodes could get scattered if you have to extend it or fill in holes while the disk is almost full. You'd probably want to preallocate a best guess, like with SunOS 4.0 NFS swap files. But that's better than being unable to extend it and consequently having to allocate something huge just in case. That could get expensive on filesystems with large inodes, such as in Unix V9. I suggest that inode 1 be used for the file-of-inodes (so it will be in the same block as the root inode, hence cached together). I'd mention where this idea has been used before, but some might find the example to be odious.
karl@asylum.SF.CA.US (Karl Auerbach) (04/11/89)
A couple of years ago we did a Unix for the Crays out at the Livermore labs. As part of this system we allowed the Unix file systems to grow (and contract) dynamically to change the number of available inodes and disk blocks. (The reason for this was because we were competing for disk space with a competing OS on the same machine.) In any case, I have forgotten the details myself, but I'm sure you can follow up, if you are interested, with the author, Karen Schaeffer, at Sandia Labs, Livermore (no, I don't know her net address.) --karl--