Rik van Riel writes:
> On Sun, 13 May 2001, Richard Gooch wrote:
> > Larry McVoy writes:
>
> > > Ha. For once you're both wrong but not where you are thinking. One
> > > of the few places that I actually hacked Linux was for exactly this
> > > - it was in the 0.99 days I think. I saved the list of I/O's in a
> > > file and filled the buffer cache with them at next boot. It
> > > actually didn't help at all.
> >
> > Maybe you did something wrong :-)
>
> How about "the data loads got instrumented, but the metadata
> loads which caused over half of the disk seeks didn't" ?
>
> (just a wild guess ... if it turns out to be true we may want
> to look into doing agressive readahead on inode blocks ;))
Caching metadata is definately part of my cunning plan. I'd like to
think that once Al's metadata-in-page-cache patches go in, we'll get
that for free.
However, that will still leave indirect blocks unordered. I don't see
a clean way of fixing that. Which is why doing things at the block
device layer has it's attractions (except it doesn't work).
Hm. Is there a reason why the page cache can't see if a a block is in
the block cache, and read it from there first?
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
