writeback: bug fixes for 2.6.35

From: Dave Chinner <[email protected]>

If a filesystem writes more than one page in ->writepage, write_cache_pages fails to notice this and continues to attempt writeback when wbc->nr_to_write has gone negative - this trace was captured from XFS:

    wbc_writeback_start: towrt=1024
    wbc_writepage: towrt=1024
    wbc_writepage: towrt=0
    wbc_writepage: towrt=-1
    wbc_writepage: towrt=-5
    wbc_writepage: towrt=-21
    wbc_writepage: towrt=-85

This has adverse effects on filesystem writeback behaviour. write_cache_pages() needs to terminate after a certain number of pages are written, not after a certain number of calls to ->writepage are made. This is a regression introduced by 17bc6c30cf6bfffd816bdc53682dd46fc34a2cf4 ("vfs: Add no_nrwrite_index_update writeback control flag"), but cannot be reverted directly due to subsequent bug fixes that have gone in on top of it.

Quoted 15 lines · On Wed, 9 Jun 2010 10:37:18 +1000 Dave Chinner <[email protected]> wrote:

From: Dave Chinner <[email protected]>

If a filesystem writes more than one page in ->writepage, write_cache_pages fails to notice this and continues to attempt writeback when wbc->nr_to_write has gone negative - this trace was captured from XFS:

    wbc_writeback_start: towrt=1024
    wbc_writepage: towrt=1024
    wbc_writepage: towrt=0
    wbc_writepage: towrt=-1
    wbc_writepage: towrt=-5
    wbc_writepage: towrt=-21
    wbc_writepage: towrt=-85

Quoted 6 lines

This has adverse effects on filesystem writeback behaviour. write_cache_pages() needs to terminate after a certain number of pages are written, not after a certain number of calls to ->writepage are made. This is a regression introduced by 17bc6c30cf6bfffd816bdc53682dd46fc34a2cf4 ("vfs: Add no_nrwrite_index_update writeback control flag"), but cannot be reverted directly due to subsequent bug fixes that have gone in on top of it.

Might be needed in -stable. Unfortunately the most important piece of information which is needed to make that decision was cunningly hidden from us behind the vague-to-the-point-of-uselessness term "adverse effects".

_what_ "adverse effects"??

Quoted 25 lines · Andrew Morton

Quoted 15 lines · On Wed, 9 Jun 2010 10:37:18 +1000 Dave Chinner <[email protected]> wrote:

From: Dave Chinner <[email protected]>

If a filesystem writes more than one page in ->writepage, write_cache_pages fails to notice this and continues to attempt writeback when wbc->nr_to_write has gone negative - this trace was captured from XFS:

    wbc_writeback_start: towrt=1024
    wbc_writepage: towrt=1024
    wbc_writepage: towrt=0
    wbc_writepage: towrt=-1
    wbc_writepage: towrt=-5
    wbc_writepage: towrt=-21
    wbc_writepage: towrt=-85

Quoted 6 lines

This has adverse effects on filesystem writeback behaviour. write_cache_pages() needs to terminate after a certain number of pages are written, not after a certain number of calls to ->writepage are made. This is a regression introduced by 17bc6c30cf6bfffd816bdc53682dd46fc34a2cf4 ("vfs: Add no_nrwrite_index_update writeback control flag"), but cannot be reverted directly due to subsequent bug fixes that have gone in on top of it.

Quoted 6 lines

Might be needed in -stable. Unfortunately the most important piece of information which is needed to make that decision was cunningly hidden from us behind the vague-to-the-point-of-uselessness term "adverse effects".

_what_ "adverse effects"??

Depends on how the specific filesystem handles a negative nr_to_write, doesn't it? I can't speak for the exact effect on anything other than XFS except to say that most ->write_page implemetnations don't handle the wbc->nr_to_write < 0 specifically...

For XFS, it results in increased CPU usage because it triggers page-at-a-time allocation (i.e no clustering), which increases overhead in the elveator due to merging requirements of single page bios and increased fragmentation due to small interleaved allocations on concurrent writeback workloads. Effectively it causes accelerated aging of XFS filesystems...

Quoted 38 lines · Dave Chinner

Quoted 25 lines · Andrew Morton

Quoted 15 lines · On Wed, 9 Jun 2010 10:37:18 +1000 Dave Chinner <[email protected]> wrote:

From: Dave Chinner <[email protected]>

If a filesystem writes more than one page in ->writepage, write_cache_pages fails to notice this and continues to attempt writeback when wbc->nr_to_write has gone negative - this trace was captured from XFS:

    wbc_writeback_start: towrt=1024
    wbc_writepage: towrt=1024
    wbc_writepage: towrt=0
    wbc_writepage: towrt=-1
    wbc_writepage: towrt=-5
    wbc_writepage: towrt=-21
    wbc_writepage: towrt=-85

Quoted 6 lines

This has adverse effects on filesystem writeback behaviour. write_cache_pages() needs to terminate after a certain number of pages are written, not after a certain number of calls to ->writepage are made. This is a regression introduced by 17bc6c30cf6bfffd816bdc53682dd46fc34a2cf4 ("vfs: Add no_nrwrite_index_update writeback control flag"), but cannot be reverted directly due to subsequent bug fixes that have gone in on top of it.

Quoted 6 lines

Might be needed in -stable. Unfortunately the most important piece of information which is needed to make that decision was cunningly hidden from us behind the vague-to-the-point-of-uselessness term "adverse effects".

_what_ "adverse effects"??

Depends on how the specific filesystem handles a negative nr_to_write, doesn't it? I can't speak for the exact effect on anything other than XFS except to say that most ->write_page implemetnations don't handle the wbc->nr_to_write < 0 specifically...

Quoted 6 lines

For XFS, it results in increased CPU usage because it triggers page-at-a-time allocation (i.e no clustering), which increases overhead in the elveator due to merging requirements of single page bios and increased fragmentation due to small interleaved allocations on concurrent writeback workloads. Effectively it causes accelerated aging of XFS filesystems...

Sorry, forgot to address the -stable part of the question.

This series is dependent on the ext4 change to use it's own writepage going into -stable first. (i.e. 8e48dcfbd7c0892b4cfd064d682cc4c95a29df32 "ext4: Use our own write_cache_pages()").

I'd suggest that all 4 patches (the ext4 patch and the three in this series) should go back to 2.6.34-stable due to the long term affect this writeback bug could have on XFS filesystems, and the sync taking too long problem has been fairly widely reported since at least .32...

From: Dave Chinner <[email protected]>

Now that the background flush code has been fixed, we shouldn't need to silently multiply the wbc->nr_to_write to get good writeback. Remove that code.

From: Dave Chinner <[email protected]>

sync can currently take a really long time if a concurrent writer is extending a file. The problem is that the dirty pages on the address space grow in the same direction as write_cache_pages scans, so if the writer keeps ahead of writeback, the writeback will not terminate until the writer stops adding dirty pages.

For a data integrity sync, we only need to write the pages dirty at the time we start the writeback, so we can stop scanning once we get to the page that was at the end of the file at the time the scan started.

This will prevent operations like copying a large file preventing sync from completing as it will not write back pages that were dirtied after the sync was started. This does not impact the existing integrity guarantees, as any dirty page (old or new) within the EOF range at the start of the scan will still be captured.

This patch will not prevent sync from blocking on large writes into holes. That requires more complex intervention while this patch only addresses the common append-case of this sync holdoff.