Bug 588930

Summary:	umount performance on ext4 has regressed
Product:	[Fedora] Fedora	Reporter:	Kees Cook <kees>
Component:	kernel	Assignee:	Eric Sandeen <esandeen>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	13	CC:	anton, dougsland, esandeen, gansalmon, itamar, jonathan, kernel-maint, michael.neale
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-05-04 21:28:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kees Cook 2010-05-04 20:41:39 UTC

Description of problem: umount on ext4 has seriously regressed, stalling for over a minute (or more):
https://bugzilla.kernel.org/show_bug.cgi?id=15906

Version-Release number of selected component (if applicable): 2.6.33


How reproducible: always


Steps to Reproduce:
1. install a Fedora 13, accepted defaults.
2. Run the following as root:

cd /tmp
dd if=/dev/zero of=test.ext4 bs=1 count=1 seek=1G
mkfs.ext4 -F test.ext4
mkdir -p /mnt/test
mount -o loop test.ext4 /mnt/test
echo $(seq 65536) | (cd /mnt/test; xargs touch)
time umount /mnt/test

  
Actual results: over a minute to perform umount.


Expected results: a few seconds.

Comment 1 Eric Sandeen 2010-05-04 21:00:36 UTC

Looks barrier related, if you change the mount -o loop to mount -o loop,nobarrier, it's speedy.

commit 68db1961bbf4e16c220ccec4a780e966bc1fece3
Author: Nikanth Karthikesan <knikanth>
Date:   Tue Mar 24 12:29:54 2009 +0100

    loop: support barrier writes
    
    Honour barrier requests in the loop back block device driver.
    In case of barrier bios, flush the backing file once before processing the
    barrier and once after to guarantee ordering. In case of filesystems that
    does not support fsync, barrier bios would be failed with -EOPNOTSUPP.
    
    Signed-off-by: Nikanth Karthikesan <knikanth>
    Signed-off-by: Jens Axboe <jens.axboe>


So you're fsyncing the loop file 2x for each barrier, and those fsyncs in turn cause cache flushes on your underlying device; once upon a time lvm didn't do anything there, but now it does ... I think you're just getting bitten by the new and improved barrier support at every level.

-Eric

Comment 2 Eric Sandeen 2010-05-04 21:28:05 UTC

Since this really seems to be an upstream-relevant bug motivated by an ubuntu bug that ubuntu seemed unable to solve, I'm going to close this as UPSTREAM and worry about it there, rather than working the ubuntu bug through the fedora bugzilla.

Comment 3 Eric Sandeen 2010-05-04 21:32:29 UTC

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/543617/comments/21

Comment 4 Michael Neale 2010-05-11 04:37:37 UTC

The mad skillz that did the new colour schemes for a new release of an os (Ubuntu 10.04) should be just as capable at being able to overcome the limitation of journal transaction and barrier blocks between every single inode update by breakfast.

Comment 5 Fedora Update System 2010-05-17 05:39:39 UTC

kernel-2.6.33.4-95.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/kernel-2.6.33.4-95.fc13

Comment 6 Fedora Update System 2010-05-19 19:17:52 UTC

kernel-2.6.33.4-95.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.