[lkml]   [2001]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Generic deferred file writing

    On Tue, 2 Jan 2001, Alexander Viro wrote:

    > Depends on a filesystem. Generally you don't want asynchronous operations
    > to grab semaphores shared with something else. kswapd knows to skip the locked
    > pages, but that's it - if writepage() is going to block on a semaphore you
    > will not know what had hit you. And while buffer-cache operations will not
    > trigger writepage() (grep for GFP_BUFFER and GFP_IO and you'll see) you have
    > no such warranties for other sources of memory pressure. If one of them
    > hits while you are holding such semaphore - you are toast.

    I just checked that and you're right, sorry for causing confusion and
    thanks for clearing this up.

    > We probably could pull it off for ext2_truncate() vs. ext2_get_block()
    > but it would not do us any good. It would give excessive exclusion for
    > operations that can be done in parallel just fine (example: we have
    > a hole from 100Kb to 200Kb. Pageouts in that area can be trivially
    > done i parallel - current code will not even try to do unrolls. With
    > your locking they will be serialized for no good reason). What for?

    Let me come back to the three phases I mentioned earlier:
    alloc_block: does only a read-only check whether a block needs to be
    allocated or not, this can be done in parallel and only needs the page
    get_block: blocks are now really allocated and this needs locking of the
    commit_block: write the allocated blocks to the inode and this now would
    use an inode specific semaphore to protect the updates of indirect blocks.

    The only problem I see is truncate, but if we move the release of unneeded
    indirect blocks to file_close, only new indirect blocks can appear while
    the file is open, but they won't change anymore, what would make lots of
    the checks easier.

    bye, Roman

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

     \ /
      Last update: 2005-03-22 12:52    [W:0.021 / U:4.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site