Skip site navigation (1) Skip section navigation (2)

Re: O_DSYNC broken on MacOS X?

From: Greg Stark <gsstark(at)mit(dot)edu>
To: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: O_DSYNC broken on MacOS X?
Date: 2010-09-30 22:07:09
Message-ID: AANLkTik6GR7sb02Jo=8cmLjg5EgUw=-S_ULWpf8iK=K7@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Sep 30, 2010 at 2:22 PM, A.M. <agentm(at)themactionfaction(dot)com> wrote:
> That is not correct. fsync and friends on Darwin synchronizes I/O and flushes dirty kernel caches to the disk which meets the specification and is distinctly different from doing nothing.

How exactly is it different from doing nothing? That is, in what
situation does doing this change in any way the behaviour from the
user's point of view versus doing nothing?

People keep saying it "meets the specification" but it's a useless
interpretation of the specification. And it requires a pretty
malicious reading of "transferred to the storage device" to read it as
"transferred it from one set of ram buffers to another more closely
associated with the actual persistent storage".


> It's too bad there is no cross-platform way to ask what level of hardware-syncing is available.

Why would the user want to ask this? As far as the user is concerned
either there are only two "levels": synced or not synced. If it's not
guaranteed to persist after a power failure it's not synced. It
doesn't matter whether it's in kernel buffers, drive buffers, or
anywhere else -- they're all the same from the user's point of view --
they're non-persistent.

The other useful syncing behaviour would be to get write barriers. But
that's a whole different api, not just a behaviour that can be
attached to fsync.



-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-10-01 00:16:52
Subject: Adding getrusage profiling data to EXPLAIN output
Previous:From: Robert HaasDate: 2010-09-30 22:01:50
Subject: Re: Patch author name on commitfest page

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group