> 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.
The trouble is that directories grow bit by bit. Directories chock
full of inode data are going to grow bit by bit to a much larger final
size. Your initial directory scan is unlikely to be sequential if
your directory is large.
> > 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.
In the worst case it's _much_ worse. You might end up doing a
sequential seek over a hundred fragmented directory blocks instead of
a sequential seek over a dozen directory blocks plus a single inode
seek. If we can be sure that directories are not fragmented, then
there is still an extra CPU and IO bandwidth cost in scanning the
extra directory blocks, but that should be more than compensated for
by the lack of the final seek for moderately sized directories. For
large directories, the extra size of the embedded inodes is going to
be a net performance drain again.
Cheers,
Stephen.