lkml.org 
[lkml]   [2012]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 5/9] writeback: introduce the pageout work
    From
    Date
    On Sat, 2012-03-03 at 21:55 +0800, Fengguang Wu wrote:
    > 13 1125 /c/linux/fs/ubifs/file.c <<do_truncation>> <===== deadlockable

    Sorry, but could you please explain once again how the deadlock may
    happen?

    > It seems they are all safe except for ubifs. ubifs may actually
    > deadlock from the above do_truncation() caller. However it should be
    > fixable because the ubifs call for writeback_inodes_sb_nr() sounds
    > very brute force writeback and wait and there may well be better way
    > out.

    I do not think this "fixable" - this is part of UBIFS design to force
    write-back when we are not sure we have enough space.

    The problem is that we do not know how much space the dirty data in RAM
    will take on the flash media (after it is actually written-back) - e.g.,
    because we compress all the data (UBIFS performs on-the-flight
    compression). So we do pessimistic assumptions and allow dirtying more
    and more data as long as we know for sure that there is enough flash
    space on the media for the worst-case scenario (data are not
    compressible). This is what the UBIFS budgeting subsystem does.

    Once the budgeting sub-system sees that we are not going to have enough
    flash space for the worst-case scenario, it starts forcing write-back to
    push some dirty data out to the flash media and update the budgeting
    numbers, and get more realistic picture.

    So basically, before you can change _anything_ on UBIFS file-system, you
    need to budget for the space. Even when you truncate - because
    truncation is also about allocating more space for writing the updated
    inode and update the FS index. (Remember, all writes are out-of-place in
    UBIFS because we work with raw flash, not a block device).

    --
    Best Regards,
    Artem Bityutskiy



    \
     
     \ /
      Last update: 2012-03-07 16:49    [W:4.654 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site