fix for slow unmount on ext4 - bug 543617 on lp

[Stefan Bader]

On 06/12/2010 04:18 PM, Daniel J Blueman wrote:
> 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

Hi Daniel,

this looks like an additional corner case from the description (I have not yet
had time to look at the actual patch). The case we are facing is that sync on
umount used to get converted into an asynchronous sync, followed by a
synchronous one. This changed in a way that the sync on umount is done only
synchronously which waits on every single page.
But the patch you pointed to definitely is something to keep in mind as well.

Cheers,
Stefan
> 
> --- [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>