lkml.org 
[lkml]   [2007]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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....

    Cheers,

    Dave.
    --
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-26 16:37    [W:0.022 / U:0.368 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site