Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!swrinde!petro!texbell!killer!rpp386!jfh From: jfh@rpp386.Dallas.TX.US (John F. Haugh II) Newsgroups: comp.unix.wizards Subject: Re: Dynamic Inode lists Summary: Assumptions we don't want to rely on too heavily. Message-ID: <15501@rpp386.Dallas.TX.US> Date: 11 Apr 89 00:15:08 GMT References: <10189@cit-vax.Caltech.Edu> <28454@apple.Apple.COM> <10301@cit-vax.Caltech.Edu> Reply-To: jfh@rpp386.Dallas.TX.US (John F. Haugh II) Organization: River Parishes Programming, Dallas TX Lines: 39 In article <10301@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (Don Speck) writes: >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. 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@rpp386.Dallas.TX.US | exceeding any speed limits" UucpNet : !killer!rpp386!jfh +-- -- Porsche Ad ------------