Re: Ext4 and the "30 second window of death"

[Sitsofe Wheeler <sitsofe@yahoo.com>]

On Wed, Apr 01, 2009 at 01:35:21PM -0400, Theodore Tso wrote:
> On Wed, Apr 01, 2009 at 04:12:21PM +0100, Matthew Garrett wrote:
> > On Wed, Apr 01, 2009 at 06:20:50AM +0100, Sitsofe Wheeler wrote:
> > 
> > > Just out of curiosity, when laptop mode is happening is there a
> > > guarantee that writes to other files won't be reordered to before the
> > > fsync? 
> > 
> > laptop-mode does two things - tweak the dirty page semantics slightly 
> > (not in an interestingly relevant way) and call sys_sync() a few seconds 
> > after something hits disk rather than cache. In contrast to Ted's 
> > suggestion that laptop-mode reduces data integrity, it actually enhances 
> > it by opportunistically ensuring that data hits disk. It's the 
> > lengthening of the commit intervals that usually accompanies it that 
> > increases the risk of data loss.
> 
> It *can* reduce data integrity; it really depends on how it's tuned
> and what scenario you're talking about.  To the extent that it uses
> sys_sync(), it could help in some cases as well, since filesystems
> that do delayed allocation will wake up when the commit interval
> fires, and then force out all writes to the disk, yes.  But before the
> commit interval, there is an increased risk of data loss --- which the
> user requested.

That's fair enough and always seemed to be part of the bargain (let the
disk spin down for longer but risk losing 30 seconds of non-synced
recent data in a crash). The result shouldn't be corruption though.

> The other subtlety comes if we add fsync() suppression to laptop mode
> --- which is something that Bart Samwel is very interested in doing
> and I talked to him at FOSDEM about this.  As Jeff Garzik recently
> pointed out, however, if we let the system reorder writes across
> fsync() boundaries, or if we combine two writes to the same block
> separated by an fsync(), and the system crashes in the middle of
> pushing all of these blocks out to the disk, we can end up trashing
> the consistency guarantees of a database such as mysql or postgres.
> It's a good point, but it only applies if we add fsync() suppression
> to laptop mode --- which we haven't done yet.

eek.

If this goes in it needs to come with scary warnings so a distro doesn't
enable it by default (think of all those sqlite database that are
springing up). I know my system is crummy, all of this is only concerned
with if the system crashes uncontrollably (which it shouldn't do) and I
don't do things that would make it safer (like mount with sync) because
I like the speed but there's a risk limit. I don't want to increase my
chances of corruption (as opposed to "just" loss of non recent data) to
be too high...

-- 
Sitsofe | http://sucs.org/~sits/