Re: O_DSYNC broken on MacOS X?

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: O_DSYNC broken on MacOS X?
Дата
Msg-id AANLkTik6GR7sb02Jo=8cmLjg5EgUw=-S_ULWpf8iK=K7@mail.gmail.com
обсуждение исходный текст
Ответ на Re: O_DSYNC broken on MacOS X?  ("A.M." <agentm@themactionfaction.com>)
Ответы Re: O_DSYNC broken on MacOS X?  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Thu, Sep 30, 2010 at 2:22 PM, A.M. <agentm@themactionfaction.com> wrote:
> That is not correct. fsync and friends on Darwin synchronizes I/O and flushes dirty kernel caches to the disk which
meetsthe 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Patch author name on commitfest page
Следующее
От: Greg Stark
Дата:
Сообщение: Adding getrusage profiling data to EXPLAIN output