🚀 go-pugleaf

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.