linux-kernel - Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070427113117.98c4f88b.akpm@linux-foundation.org>
Date:	Fri, 27 Apr 2007 11:31:17 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Mike Galbraith <efault@....de>,
	LKML <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS
 is under heavy write load (massive starvation)

On Fri, 27 Apr 2007 08:18:34 -0700 (PDT) Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> 	echo 5 > /proc/sys/vm/dirty_background_ratio
> 	echo 10 > /proc/sys/vm/dirty_ratio

That'll help a lot.

ext3's problem here is that a single fsync() requires that ext3 sync the
whole filesystem.  Because

- a journal commit can contain metadata from multiple files, and if we
  want to journal one file's metadata via fsync(), we unavoidably journal
  all the other file's metadata at the same time.

- ordered mode requires that we write a file's data blocks prior to
  journalling the metadata which refers to those blocks.

net result: syncing anything syncs the whole world.

There are a few areas in which this could conceivably be tuned up: if a
particular file doesn't currently have any metadata in the commit, we don't
actually need to sync its data blocks: we could just transfer them into
next commit.  Hard, unlikely to be of benefit.

Arguably, we could get away without syncing overwritten data blocks.  Users
would occasionally see older data than they otherwise would have after a
crash.  Could help a bit in some circumstances.

But none of this explains a 20-minute hang, unless a *lot* of fsyncs are
being performed, perhaps.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/