Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932236AbZDBUIU (ORCPT ); Thu, 2 Apr 2009 16:08:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755381AbZDBUIF (ORCPT ); Thu, 2 Apr 2009 16:08:05 -0400 Received: from rv-out-0506.google.com ([209.85.198.231]:56855 "EHLO rv-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756218AbZDBUID (ORCPT ); Thu, 2 Apr 2009 16:08:03 -0400 MIME-Version: 1.0 In-Reply-To: References: <200903311452.05210.info@gnebu.es> <49D2A5AB.1090704@ursus.ath.cx> <20090401015010.GB4529@mit.edu> <20090401052050.GA20456@sucs.org> <20090401151219.GA12285@srcf.ucam.org> <20090401173521.GA15423@mit.edu> <20090401174336.GA14726@srcf.ucam.org> <20090402182925.GA4502@srcf.ucam.org> Date: Thu, 2 Apr 2009 13:07:46 -0700 Message-ID: <2c0942db0904021307w2c311dc2s9bf31c9ed3c1e6ba@mail.gmail.com> Subject: Re: Ext4 and the "30 second window of death" From: Ray Lee To: david@lang.hm Cc: Matthew Garrett , Theodore Tso , Sitsofe Wheeler , "Andreas T.Auer" , Alberto Gonzalez , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1275 Lines: 29 On Thu, Apr 2, 2009 at 11:44 AM, 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/