From: Alberto Gonzalez <info@gnebu.es>
To: Theodore Tso <tytso@mit.edu>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Ext4 and the "30 second window of death"
Date: Wed, 1 Apr 2009 00:02:46 +0200 [thread overview]
Message-ID: <200904010002.47077.info@gnebu.es> (raw)
In-Reply-To: <20090331134547.GJ13356@mit.edu>
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.
next prev parent reply other threads:[~2009-03-31 22:03 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-29 10:24 Ext4 and the "30 second window of death" Alberto Gonzalez
2009-03-31 12:25 ` Theodore Tso
2009-03-31 12:52 ` Alberto Gonzalez
2009-03-31 13:45 ` Theodore Tso
2009-03-31 14:45 ` Alberto Gonzalez
2009-04-01 0:04 ` Theodore Tso
2009-04-01 1:14 ` Alberto Gonzalez
2009-03-31 22:02 ` Alberto Gonzalez [this message]
2009-03-31 23:22 ` Andreas T.Auer
2009-04-01 1:25 ` Alberto Gonzalez
2009-04-01 1:50 ` Theodore Tso
2009-04-01 5:20 ` Sitsofe Wheeler
2009-04-01 15:12 ` Matthew Garrett
2009-04-01 17:35 ` Theodore Tso
2009-04-01 17:43 ` Matthew Garrett
2009-04-01 21:21 ` Ray Lee
2009-04-01 21:26 ` Matthew Garrett
2009-04-02 11:25 ` Sitsofe Wheeler
2009-04-02 18:22 ` david
2009-04-02 18:29 ` Matthew Garrett
2009-04-02 18:44 ` david
2009-04-02 20:07 ` Ray Lee
2009-04-02 20:59 ` Andreas T.Auer
2009-04-02 23:38 ` Theodore Tso
2009-04-03 0:00 ` Matthew Garrett
2009-04-03 7:33 ` Pavel Machek
2009-04-03 8:14 ` Andreas T.Auer
2009-04-02 22:36 ` Bron Gondwana
2009-04-02 23:46 ` Matthew Garrett
2009-04-03 0:55 ` david
2009-04-03 1:06 ` Matthew Garrett
2009-04-03 1:16 ` david
2009-04-03 1:19 ` Matthew Garrett
2009-04-03 1:24 ` david
2009-04-03 1:36 ` Matthew Garrett
2009-04-03 3:08 ` david
2009-04-03 13:42 ` Matthew Garrett
2009-04-03 4:54 ` Theodore Tso
2009-04-03 11:09 ` Sitsofe Wheeler
2009-04-03 13:07 ` Alberto Gonzalez
2009-04-03 13:45 ` Matthew Garrett
2009-04-02 18:34 ` Nick Piggin
2009-04-02 18:38 ` Matthew Garrett
2009-04-02 18:56 ` Nick Piggin
2009-04-02 23:47 ` Matthew Garrett
2009-04-03 0:59 ` david
2009-04-03 1:09 ` Matthew Garrett
2009-04-03 1:17 ` david
2009-04-03 1:22 ` Matthew Garrett
2009-04-03 2:22 ` Ric Wheeler
2009-04-02 21:47 ` david
2009-04-06 21:32 ` supporting laptops fs-semantic changes (was Re: Ext4 and the "30 second window of death") Linda Walsh
2009-04-02 11:37 ` Ext4 and the "30 second window of death" Sitsofe Wheeler
2009-04-01 8:51 ` Andreas T.Auer
2009-04-03 7:13 ` Bojan Smojver
2009-04-05 4:07 ` Bojan Smojver
2009-04-05 4:51 ` Bojan Smojver
2009-04-05 5:41 ` Bojan Smojver
2009-04-05 17:27 ` Ed Tomlinson
-- strict thread matches above, loose matches on Subject: below --
2009-04-05 18:13 Tomasz Chmielewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200904010002.47077.info@gnebu.es \
--to=info@gnebu.es \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox