Re: [00/17] Large Blocksize Support V3

From: Avi Kivity
Date: Thu Apr 26 2007 - 09:53:24 EST

David Chinner wrote:
On Thu, Apr 26, 2007 at 05:48:12PM +1000, Nick Piggin wrote:
Christoph Lameter wrote:
On Thu, 26 Apr 2007, Nick Piggin wrote:

No I don't want to add another fs layer.
Well maybe you could explain what you want. Preferably without redefining the established terms?
Support for larger buffers than page cache pages.

The problem with this approach is that it turns around the whole
way we look at bufferheads. Right now we have well defined 1:n
mapping of page to bufferheads and so we tpyically lock the
page first them iterate all the bufferheads on the page.

Going the other way, we need to support m:n which we means
the buffer has to become the primary interface for the filesystem
to the page cache. i.e. we need to lock the bufferhead first, then
iterate all the pages on it. This is messy because the cache indexes
via pages, not bufferheads. hence a buffer needs to point to all the
pages in it explicitly, and this leads to interesting issues with

Why is it necessary to assume that one filesystem block == one buffer? Is it for atomicity, efficiency, or something else?

error compiling committee.c: too many arguments to function

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at