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:	Wed, 1 Apr 2009 00:02:46 +0200
From:	Alberto Gonzalez <info@...bu.es>
To:	Theodore Tso <tytso@....edu>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Ext4 and the "30 second window of death"

On Tuesday 31 March 2009 15:45:47 Theodore Tso wrote:
> On Tue, Mar 31, 2009 at 02:52:05PM +0200, Alberto Gonzalez wrote:
> > You've proposed that in laptop mode, fsync's should be held until next
> > write cycle (say every 30 seconds) so that the disk is not spun up
> > unnecessarily, wasting battery and shortening it's lifespan too. I
> > absolutely agree with this, and as a trade-off I'm ok with losing my last
> > paragraph even if I did hit Ctrl+S to save it a few seconds before a
> > crash. But again, with Ext4 will I just lose that last paragraph or the
> > whole book in this case?
>
> Laptop mode is already set up such that the moment the disk spins up,
> any pending writes are immediately flushed to disk --- the idea being
> that if the disk is spinning, we might as well take advantage of it to
> get everything pushed out to disk.  As long as we actually keep a
> linked list of those fsync's which were "held up", and we make sure
> all of the delayed allocation blocks are also allocated before we push
> them out, the right thing will happen.  If we just ignore the fsync's,
> then we might not allocate the delayed allocation blocks.  So
> basically, we need to be careful about how we implement this addition
> to laptop_mode.

In fact, thinking about it, this option would be the ideal one for desktops 
and especially laptops (servers running databases are a different thing). What 
we need is that _no_ application uses fsync. The decision as to when the data 
should be written to disk should be left to the filesystem. And then the user 
can choose how often they want this to happen (every 5, 15, 30, 60... 
seconds). So if Ext4 could have a "nofsync" mount option that would disable 
fsync from applications (i.e, it wouldn't honor an fsync call), that would be 
wonderful. But then of course we have to make sure that if the kernel crashes 
(or there's a power-off, etc..), we will just lose the new data that hasn't 
been written to disk, but the old data will still be there. So maybe this 
could be achieved with mounting the filesystem with nofsync, nodelalloc? 

> The bottom line is that it *can* be implemented safely, but there are
> some things that we would need to pay attention to in order to make
> sure it *was* safe.

If you could do this, many of us would be willing to buy you a beer :)

>
> 						- Ted

And of course, thanks for your patience with this issue. And sorry for all 
you're having to take from us uninformed but somehow worried users (I run Ext4 
now, but added the nodelalloc option when all this started).

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