[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2c0942db0904021307w2c311dc2s9bf31c9ed3c1e6ba@mail.gmail.com>
Date: Thu, 2 Apr 2009 13:07:46 -0700
From: Ray Lee <ray-lk@...rabbit.org>
To: david@...g.hm
Cc: Matthew Garrett <mjg59@...f.ucam.org>,
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 2, 2009 at 11:44 AM, <david@...g.hm> wrote:
> let's not talk a database here, let's talk something simpler, like a POP3
> mail client (even though I strongly favor IMAP ;-)
>
> it wants to have the message saved before it deletes it from the server.
>
> how should it try to do this?
>
> the only portable method is to fsync the file after it's written and before
> sending the delete to the server.
>
> so your mail client _should_ issue fsync calls.
That's just not the case. Every POP fetcher I've seen offers an option
to leave seen messages on the server for some period measured in days.
Setting it to one day means that the data will eventually get flushed
by the time the message is deleted.
So, no, the mail client does not have to issue fsync()s at all. (If
dirty data can hang around unwritten for 24 hours, I'd argue that's a
misfeature of the filesystem or kernel.)
Alternately, a client could fetch once every half hour at which point
the cost of an fsync is amortized over all the fetched messages.
--
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/
Powered by blists - more mailing lists