From: Bojan Smojver <bojan@rexursive.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Ext4 and the "30 second window of death"
Date: Fri, 3 Apr 2009 07:13:41 +0000 (UTC) [thread overview]
Message-ID: <loom.20090403T060217-420@post.gmane.org> (raw)
In-Reply-To: <20090331122540.GB13356@mit.edu>
Theodore Tso <tytso <at> mit.edu> writes:
> The replace-via-truncate and replace-via-rename workarounds are there
> for the benefit of KDE, and GNOME, which in some configurations
> apparently will replace hundreds of dot files when the desktop is
> started up, for no reason that I can understand.
Maybe it would be useful if we had IN_SYNC event in inotify (meaning all buffers
of a closed file have been synced to disk, either implicitly or by fsync() - not
important). Then we could have these apps to do something like this on
configuration change:
1. Backup by link("foo","foo~"), unless we are watching "foo" for IN_SYNC event.
2. Open "foo" and read it.
3. Create "foo.new" and put new stuff in it.
4. Close "foo.new".
5. Rename "foo.new" into "foo".
6. Put a watch on "foo" for IN_SYNC, unless we already have one.
In the regular loop of the app:
1. When the event IN_SYNC turns up for "foo", remove "foo~".
2. Remove the watch.
No fsync() in sight, all atomic and no chance of losing data. If things go
haywire, we shall have fully committed "foo~" on startup, which we then just
rename into most likely broken "foo" and continue. If we don't have "foo~", it
must mean "foo" is OK.
Something like this may even work for rsync (slightly different flow of events,
probably watching from another thread).
When throwing stones, please limit yourself to less than 5kg specimens... :-)
--
Bojan
next prev parent reply other threads:[~2009-04-03 7:14 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-29 10:24 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
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 [this message]
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
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=loom.20090403T060217-420@post.gmane.org \
--to=bojan@rexursive.com \
--cc=linux-kernel@vger.kernel.org \
/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
Powered by JetHome