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?
|
Список | 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 по дате отправления: