linux-kernel - Re: Ext4 and the "30 second window of death"

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: <20090403134535.GC19774@srcf.ucam.org>
Date:	Fri, 3 Apr 2009 14:45:35 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Theodore Tso <tytso@....edu>, david@...g.hm,
	Sitsofe Wheeler <sitsofe@...oo.com>,
	"Andreas T.Auer" <andreas.t.auer_lkml_73537@...us.ath.cx>,
	Alberto Gonzalez <info@...bu.es>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Ext4 and the "30 second window of death"

On Fri, Apr 03, 2009 at 12:54:14AM -0400, Theodore Tso wrote:

> More to the point, if an application is insane enough to push 2.5
> megabytes to disk every single time you click on a web page (this is
> excluding the cache; I had my firefox cache pointed at /tmp when I did
> this measurement), *and* you are running the WiFi for the browser,
> *and* the browser is running flash applications, etc., whether you
> defer the writes or not, you're going to be burning a lot of power.
> Fundamentally, if an application needs to be writing hundreds of files
> or hundreds of kilibytes or more of data all the time, there's
> something wrong with the application.

Yes. If applications are fsync()ing too often then the obvious fix is to 
deal with those applications, and that's something we've been successful 
with in other fields of power management.

> If some KDE applications needs to rewrite hundreds of files at desktop
> startup, when the user hasn't even changed any configuration options
> yet (this is that desktop **startup**, mind you, where this was
> reported), then you're going to burning a lot of power.  Anything we
> do at the filesystem level is really going to be at the margins.

Not really. Desktop startup is a one-off cost and has no significant 
impact on your overall power budget. There's little worthwhile 
optimisation there from a power management point of view.

> The annoying thing is the applications programmers aren't willing to
> fix their d*mn applications, and instead heap all of the blame on the
> filesystem.  I will be the first to admit that filesystem designers
> have to do their part, and once I realized how bad and sloppy people
> had gotten with fsync(), and needlessly rewriting files, I implemented
> the ext4 workaround patches *first*.  I only started talking about how
> application programmers might make changes to obey the established
> standards and work with other filesystems after I had put my own house
> in order.  These are system-wide problems we are talking about, that
> will require system-wide solutions.  I can provide workarounds for
> existing application behaviours, but claiming that applications can
> never change, and we must always accomodate the way applications are
> currently working and are designed is going to be a losing strategy
> for us all.

>From a power management perspective, anything that requires applications 
to call fsync() more frequently is a bad thing. So filesystems that 
reorder metadata operations are a bad thing. The fix isn't to add 
fsync() to applications, the fix is to ensure that filesystems don't 
force applications to do so.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/