Messages in this thread | | | Subject | Re: Filesystem optimization.. | Date | Wed, 07 Jan 1998 10:45:56 +0800 | From | "Michael O'Reilly" <> |
| |
In message <11617.884140221@ISI.EDU>, Craig Milo Rogers writes: > >When doing a path lookup, the directory must already have been > >read. Embedding the inode has the neat advantage that reading the > >directory automatically pulls the inode in at a very low cost. > > Maybe, maybe not. If the directory entry you seek is not at > the beginning of the directory, you may have to read more directory > blocks from disk (proportional to the increased size of the enhanced > directory entry) to reach the one you want.
True, but sequential reads are much much cheaper than seeks.
> If the enhanced directory blocks are cached and the > pre-enhancement inode blocks wouldn't have been cached... that's > probably a reasonable I/O improvement. If the enhanced directory > blocks are not cached, and are not allocated consecutively and > read-ahead... this could be a performance penalty.
No worse than the current arrangement where you need to seek to a seperate part of the disk for inodes.
In the worst case it's the same as it was. In the best case it's faster.
> What it boils down to, I think, is that someone needs to > implement this idea so it can be tested in real systems. The result > of the tests will determine whether the time spend implementing it was > worthwhile. :-)
Indeed. :)
Michael, agitating for an extra day in every week..
| |