From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MieUK-0003BE-7j for qemu-devel@nongnu.org; Tue, 01 Sep 2009 21:18:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MieUE-00039C-UA for qemu-devel@nongnu.org; Tue, 01 Sep 2009 21:18:15 -0400 Received: from [199.232.76.173] (port=56147 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MieUE-000397-Qq for qemu-devel@nongnu.org; Tue, 01 Sep 2009 21:18:10 -0400 Received: from mx20.gnu.org ([199.232.41.8]:55595) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MieUE-0003HP-FB for qemu-devel@nongnu.org; Tue, 01 Sep 2009 21:18:10 -0400 Received: from mail2.shareable.org ([80.68.89.115]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MieUD-0001y9-HM for qemu-devel@nongnu.org; Tue, 01 Sep 2009 21:18:09 -0400 Date: Wed, 2 Sep 2009 02:18:01 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 2/4] block: use fdatasync instead of fsync Message-ID: <20090902011801.GA3591@shareable.org> References: <20090831201627.GA4811@lst.de> <20090831201709.GB4874@lst.de> <20090901160409.GA22629@lst.de> <20090902003454.GE1321@shareable.org> <20090902003705.GA13309@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090902003705.GA13309@lst.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Blue Swirl , qemu-devel@nongnu.org Christoph Hellwig wrote: > On Wed, Sep 02, 2009 at 01:34:54AM +0100, Jamie Lokier wrote: > > fdatasync is common among the big commercial unixes which were still > > being actively developed a few years ago, but fsync is universal - > > it's very old. > > > > Neither OpenBSD nor FreeBSD have fdatasync. > > > > mingw32 is a thin wrapper around Windows. Windows as far as I can > > tell doesn't have an equivalent of fdatasync, although it does have an > > equivalent of O_DIRECT|O_SYNC (but documentation contradicts itself > > regarding whether the combination flushes metadata on each write). > > Yeah, I'll just add a > > #ifndef _POSIX_SYNCHRONIZED_IO > # define fdatasync(fd) fsync(fd) > #endif > > Now I'm pretty sure we'll find various fuckups where headers define > fdatasync but not _POSIX_SYNCHRONIZED_IO or vice versa, but I can > outsource adding workarounds for that to people with those broken > setups. I've now learned that Windows has equivalents of O_DSYNC and fsync, but not O_SYNC and fdatasync, and that the O_DSYNC equivalent doesn't flush metadata needed to access newly allocated data; it only commits overwrites, and that the fsync equivalent does try to flush the drive's volatile write cache after writing metadata, but only on some versions with some settings and some drivers and possibly some types of drive. Not that you could tell any of that from the documentation. Why do I have the feeling some unixes are the same. No wonder the SQLite folks say, paraphrasing, "we call fsync or something else; we can't help you beyond that point and many OSes have rumoured bugs in this area or don't fulfil what these functions promise". -- Jamie