Re: Filesystem optimization..

Michael O'Reilly (michael@metal.iinet.net.au)
Wed, 07 Jan 1998 10:45:56 +0800


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..