From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MiEqa-00057I-Nv
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 17:55:32 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MiEqW-00055z-5e
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 17:55:32 -0400
Received: from [199.232.76.173] (port=59486 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MiEqW-00055w-2S
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 17:55:28 -0400
Received: from verein.lst.de ([213.95.11.210]:40461)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1MiEqV-0000iQ-Fy
	for qemu-devel@nongnu.org; Mon, 31 Aug 2009 17:55:27 -0400
Date: Mon, 31 Aug 2009 23:55:25 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 2/4] block: use fdatasync instead of fsync
Message-ID: <20090831215525.GA8135@lst.de>
References: <20090831201627.GA4811@lst.de> <20090831201709.GB4874@lst.de>
	<20090831215138.GA24318@shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090831215138.GA24318@shareable.org>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jamie Lokier <jamie@shareable.org>
Cc: qemu-devel@nongnu.org

On Mon, Aug 31, 2009 at 10:51:38PM +0100, Jamie Lokier wrote:
> Christoph Hellwig wrote:
> > 
> > If we are flushing the caches for our image files we only care about the
> > data (including the metadata required for accessing it) but not things
> > like timestamp updates.  So use fdatasync instead of fsync to implement
> > the flush operations.
> 
> > -    fsync(s->fd);
> > +    fdatasync(s->fd);
> 
> I believe fsync was used because of uncertainty about whether
> fdatasync reliably flushes the necessary metadata to access the data
> on all hosts, after things like writing to holes and extending a file.
> 
> I'm still not sure if fdatasync provides that guarantee on Linux.

fdatasync is defined to provide that guarantee, and modulo the whole
clusterfuck around volatile write caches it does the right thing
thing on common Linux filesystems.