[lkml]   [2007]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [00/17] Large Blocksize Support V3
On Thu, Apr 26, 2007 at 04:53:00PM +0300, Avi Kivity wrote:
> David Chinner wrote:
> >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
> >locking.
> >
> Why is it necessary to assume that one filesystem block == one buffer?
> Is it for atomicity, efficiency, or something else?

By definition, really - each filesystem block has it's own state and
it's own disk mapping and so we need something to carry that
information around....

Dave Chinner
Principal Engineer
SGI Australian Software Group
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-04-26 16:37    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean