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]

Date:	Fri, 3 Apr 2009 02:06:00 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	david@...g.hm
Cc:	Theodore Tso <tytso@....edu>, 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 Thu, Apr 02, 2009 at 05:55:11PM -0700, david@...g.hm wrote:
> On Fri, 3 Apr 2009, Matthew Garrett wrote:
> >Then they shouldn't use a mail client that fsync()s.
> 
> so they need to use one mail client when they want to have good battery 
> life and a different one when they are plugged in to power?

They need to make a decision about whether they care about their mailbox 
being precisely in sync with their server or not, and either use a 
client that adapts appropriately or choose a client that behaves 
appropriately. It's certainly not the kernel's business.

> >No. Ignoring fsync() makes it difficult for an application to
> >inappropriately spin up a disk - but it also makes it *impossible* for
> >an application to save data that it genuinely needs to. Doing this in
> >kernel means that you have no granularity. You ignore the inappropriate
> >fsync()s, but you also ignore the ones that are vitally important. I've
> >no objection to the kernel supporting this functionality, but it should
> >be /proc/sys/vm/fuck-my-data-harder rather than
> >/proc/sys/vm/laptop-mode.
> >
> >Power management is a tradeoff. Sometimes providing correct
> >functionality costs more than providing incorrect functionality. In
> >general we strive to carry on providing applications the behaviour they
> >expect even if it costs us more power - the alternative leads to users
> >disabling power management functionality because they can't trust it.
> >Throwing data away isn't an acceptable tradeoff for an extra three
> >minutes of battery life for most users.
> 
> I would agree with you if it was three minutes of battery life, but what 
> if it's an extra hour? (easily possible if the fsyncs make the difference 
> between the drive running all the time and waking up every 5 min for a few 
> seconds)

If you can demonstrate a real world use case where the hard drive 
(typically well under a watt of power consumption on modern systems) 
spindown policy will be affected sufficiently pathologically by a mail 
client that you lose an hour of battery life, then I'd rethink this. But 
mostly I'd conclude that this was an example of an inappropriate 
spindown policy.

-- 
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/