[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    [W:0.021 / U:0.788 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site