Dynamic Inode lists

[John F. Haugh II]

In article <10301 at cit-vax.Caltech.Edu> mangler at cit-vax.Caltech.Edu (Don Speck) writes:
>In article <28454 at apple.Apple.COM>, fair at Apple.COM (Erik E. Fair) writes:
>> In the referenced article, mangler at 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.

Why not have the inumber contain information concerning the location on
the partition of itself?  Inumbers could be expanded to 32 bits, with
the first 28 giving the block number [ 1K blocks ] on the device and the
last 4 giving the inode within the block.  Keep that list of blocks
organized in a file.

Now you have no need to check the indirect block since you can directly
locate the inode given the inumber.  You may also expand the file by
grabbing a new block and making up a new group of inumbers.  You would
only have to read the ilist file when looking for new inumbers to use
and the inumber cache is empty [ same as now, except the search is
more expensive ].

>I'd mention where this idea has been used before, but some might find
>the example to be odious.

Yup.  It was sort-of used in VMS.  Directories contained pointers into
a giant index file.  An excellent example of how not to write a file
system.
-- 
John F. Haugh II                        +-Quote of the Week:-------------------
VoiceNet: (214) 250-3311   Data: -6272  | "Porsche does not recommend
InterNet: jfh at rpp386.Dallas.TX.US       |  exceeding any speed limits"
UucpNet : <backbone>!killer!rpp386!jfh  +--        -- Porsche Ad   ------------