lkml.org 
[lkml]   [1998]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Filesystem optimization..
Date
From

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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.059 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site