lkml.org 
[lkml]   [2010]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] new ->perform_write fop
    On Fri, May 21, 2010 at 11:15:18AM -0400, Christoph Hellwig wrote:
    > Nick, what exactly is the problem with the reserve + allocate design?
    >
    > In a delalloc filesystem (which is all those that will care about high
    > performance large writes) the write path fundamentally consists of those
    > two operations. Getting rid of the get_blocks mess and replacing it
    > with a dedicated operations vector will simplify things a lot.

    Nothing wrong with it, I think it's a fine idea (although you may still
    need a per-bh call to connect the fs metadata to each page).

    I just much prefer to have operations after the copy not able to fail,
    otherwise you get into all those pagecache corner cases.

    BTW. when you say reserve + allocate, this is in the page-dirty path,
    right? I thought delalloc filesystems tend to do the actual allocation
    in the page-cleaning path? Or am I confused?


    > Punching holes is a rather problematic operation, and as mentioned not
    > actually implemented for most filesystems - just decrementing counters
    > on errors increases the chances that our error handling will actually
    > work massively.

    It's just harder for the pagecache. Invalidating and throwing out old
    pagecache and splicing in new pages seems a bit of a hack.



    \
     
     \ /
      Last update: 2010-05-22 04:33    [W:0.021 / U:30.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site