fix for slow unmount on ext4 - bug 543617 on lp

[Daniel J Blueman]

On Wed, Jun 9, 2010 at 8:06 PM, Kees Cook <kees.cook at canonical.com> wrote:
> Hi Stefan,
>
> On Mon, Jun 07, 2010 at 02:10:43PM +0200, Stefan Bader wrote:
>> Ok, so upstream seems to have officially reverted the changes for now. Given
>> that the changes in that area seem to have unexpected side effects and we do not
>> really know the other patch would not do the same. When reverting the
>> work-around we got huge sync times. IIRC the side effects of that patch were not
>> as bad timewise (2 seconds?). So maybe for now, we stay with what we got and
>> wait for the proper upstream solution?
>
> Upstream gave up on fixing the problem?  Argh.
>
> Huge sync times in Lucid?  When what was changed?
>
> I think we need to revert 5e1941884c700b7b97bcad52c2d8212ac56a7ebc even
> if there isn't a good fix for the umount slow-down since it solves the
> slow umount only under certain conditions, and makes other more common
> umount scenarios slower.

Dave Chinner just committed a ratified fix [1] for this upstream,
which may be a good cherry-pick.

Dan

--- [1]

commit d87815cb2090e07b0b0b2d73dc9740706e92c80c
Author: Dave Chinner <dchinner at redhat.com>
Date:   Wed Jun 9 10:37:20 2010 +1000

    writeback: limit write_cache_pages integrity scanning to current EOF

    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.

    Signed-off-by: Dave Chinner <dchinner at redhat.com>
    Reviewed-by: Christoph Hellwig <hch at lst.de>
    Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
-- 
Daniel J Blueman