[opensuse-kernel] Slow umount in openSUSE 11.3
Hi,
we have a report of slow umount behavior in openSUSE 11.3. Basically, the
problem is that if umount is called while there is still big amount of
dirty data against the filesystem, kernel goes on writing it but because of
a bug in writeback code, the writes happen in synchronous mode and thus the
throughput is disastrous.
I actually have a reasonably non-intrusive patch fixing this (because SLERT
11 SP1 had the problem as well) but the patch changes kABI (struct
writeback_control and some exported functions like writeback_inodes_sb())
and there's no reasonable way around that.
So my question is: Shall we live with the bug or shall we break the kABI?
I think the bug is anoying enough that the kABI breakage could be warranted
but I'd like to hear others opinion on this...
Honza
PS: The patch is attached for convenience.
--
Jan Kara
On Thu, 13 Jan 2011, Jan Kara wrote:
we have a report of slow umount behavior in openSUSE 11.3. Basically, the problem is that if umount is called while there is still big amount of dirty data against the filesystem, kernel goes on writing it but because of a bug in writeback code, the writes happen in synchronous mode and thus the throughput is disastrous.
I actually have a reasonably non-intrusive patch fixing this (because SLERT 11 SP1 had the problem as well) but the patch changes kABI (struct writeback_control and some exported functions like writeback_inodes_sb()) and there's no reasonable way around that.
So my question is: Shall we live with the bug or shall we break the kABI? I think the bug is anoying enough that the kABI breakage could be warranted but I'd like to hear others opinion on this...
PS: The patch is attached for convenience.
What part of kABI exactly breaks? (I haven't built the kernel with the patch applied yet). Is that solely because of new field addition to struct wb_writeback_args, struct bdi_work and argument change for bdi_start_writeback()? If so, I'd personally be very surprised if any 3rd party module would depend on those. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu 13-01-11 16:54:46, Jiri Kosina wrote:
On Thu, 13 Jan 2011, Jan Kara wrote:
we have a report of slow umount behavior in openSUSE 11.3. Basically, the problem is that if umount is called while there is still big amount of dirty data against the filesystem, kernel goes on writing it but because of a bug in writeback code, the writes happen in synchronous mode and thus the throughput is disastrous.
I actually have a reasonably non-intrusive patch fixing this (because SLERT 11 SP1 had the problem as well) but the patch changes kABI (struct writeback_control and some exported functions like writeback_inodes_sb()) and there's no reasonable way around that.
So my question is: Shall we live with the bug or shall we break the kABI? I think the bug is anoying enough that the kABI breakage could be warranted but I'd like to hear others opinion on this...
PS: The patch is attached for convenience.
What part of kABI exactly breaks? (I haven't built the kernel with the patch applied yet). Is that solely because of new field addition to struct wb_writeback_args, struct bdi_work and argument change for bdi_start_writeback()? And writeback_inodes_sb(). bdi_start_writeback() in fact isn't exported so that change does not matter. writeback_inodes_sb() can be easily called by 3rd party filesystems so that matters I think. But luckily new writeback_inodes_sb() with locked==0 behaves the same way as the old writeback_inodes_sb() so we could probably handle that by creating a new function instead of changing the old one.
If so, I'd personally be very surprised if any 3rd party module would depend on those. For struct writeback_control, we would have to hope (as some exported functions take that structure as an argument - e.g. writepage() prototype).
Honza
--
Jan Kara
Hi Jan, This bug is also tracked in https://bugzilla.novell.com/show_bug.cgi?id=617437
I actually have a reasonably non-intrusive patch fixing this (because SLERT 11 SP1 had the problem as well) but the patch changes kABI (struct writeback_control and some exported functions like writeback_inodes_sb()) and there's no reasonable way around that.
So my question is: Shall we live with the bug or shall we break the kABI? I think the bug is anoying enough that the kABI breakage could be warranted but I'd like to hear others opinion on this...
In case you do not want to fix the kernel I kindly ask to work around the issue in user space tools. As documented in the above bugzilla entry a simple workaround is to call sync() on the relevant filesystem before doing the actual umount() system call. I think that this would require a one line patch for both util-linux and busybox. Best regards Martin Konold Robert Bosch GmbH Automotive Electronics (RtP2/TEF72) Postfach 13 42 72703 Reutlingen GERMANY www.bosch.com external.martin.konold@de.bosch.com Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000; Aufsichtsratsvorsitzender: Hermann Scholl; Geschäftsführung: Franz Fehrenbach, Siegfried Dais; Bernd Bohr, Rudolf Colm, Volkmar Denner, Wolfgang Malchow, Peter Marks, Peter Tyroller; Stefan Asenkerschbaumer, Uwe Raschke, Wolf-Henning Scheider -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (3)
-
EXTERNAL Konold Martin (Firma, RtP2/TEF72) -
Jan Kara -
Jiri Kosina