On Tue, Oct 12, 1999 at 12:52:11PM +0100, Stephen C. Tweedie wrote:
> On 11 Oct 1999 17:58:54 -0500, ebiederm+eric@ccr.net (Eric W. Biederman)
> said:
> > Ultimately we really want to have indirect blocks, and
> > the directory in the page cache as it should result in
> > more uniform code, and faster partial truncates (as well as faster
> > syncs).
>
> There is one major potential future problem with moving this to the page
> cache. At some point I want to be able to extend the large (64G) memory
> support on Intel to include the page cache in high memory. The buffer
> cache would still live in low memory. [..]
So I guess we need to look at why people want to stuff metadata in the page
cache. For me, I have a problem in NTFS that all metadata is stored in files,
and comes in chunks that can be multiples of the block size of the device/fs.
The current tiny prototype I have (started during the summer and then
forgotten about) was stuffing these in the page cache, on the grounds that
in practice metadata blocks never exceeded the page size, though I don't
believe this is set in stone.
--
"Pascal is Pascal is Pascal is dog meat."
-- M. Devine and P. Larson, Computer Science 340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/