[lkml]   [2007]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ext3][kernels >= at least] KDE going comatose when FS is under heavy write load (massive starvation)
    Andrew Morton wrote:
    > Yes, there can be issues with needing to allocate journal space within the
    > context of a commit. But

    no-no, this isn't required. we only need to mark pages/blocks within
    transaction, otherwise race is possible when we allocate blocks in transaction,
    then transacton starts to commit, then we mark pages/blocks to be flushed
    before commit.

    > a) If the page has newly allocated space on disk then the metadata which
    > refers to that page is already in the journal: no new journal space
    > needed.
    > b) If the page doesn't have space allocated on disk then we don't need
    > to write it out at ordered-mode commit time, because the post-recovery
    > filesystem will not have any references to that page.
    > c) If the page is dirty due to overwrite then no metadata update was required.
    > IOW, under what circumstances would an ordered-mode commit need to allocate
    > space for a delayed-allocate page?

    no need to allocate space within commit thread, I think. only to take care
    of the race I described above. in hackish version of data=ordered for delayed
    allocation I used counter of submitted bio's with newly-allocated blocks and
    commit thread waits for the counter to reach 0.

    > However b) might lead to the hey-my-file-is-full-of-zeroes problem.

    thanks, Alex

    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-05-04 08:21    [W:0.022 / U:11.848 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site