On Sep 30, 2010, at 5:02 PM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Oh, I missed that. Actually, I wasn't really so concerned with
>> whether his benchmark is correct. I *am* concerned about being broken
>> out of the box on MacOS X.
>
> Actually, the problem with OSX is that OSX is broken out of the box,
> at least by that standard. The system's normal configuration is that
> fsync() does nothing,
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.
"The fsync() function can be used by an application to indicate that all data for the open file description named by
fildesis to be transferred to the storage device associated with the file described by fildes in an
implementation-dependentmanner."
http://opengroup.org/onlinepubs/007908799/xsh/fsync.html
"On MacOS X, fsync() always has and always will flush all file data
from host memory to the drive on which the file resides."
http://lists.apple.com/archives/Darwin-dev/2005/Feb/msg00072.html
> I'm not sure whether we should select fsync_writethrough as the default
> on OSX. We don't make an equivalent attempt to prevent OS or storage
> malfeasance on other Unixoid platforms --- in fact, I'd say OSX is a bit
> ahead of the game in that you *can* force writethrough without resorting
> to arcane hacks with hdparm or some such.
>
> We could definitely stand to be a bit more verbose about documenting
> the platform-specific issues in this area.
Not only is this issue platform-specific, it is also bus-, controller- and disk-specific. Luckily, hardware that ships
fromApple responds properly to F_FULLFSYNC. It's too bad there is no cross-platform way to ask what level of
hardware-syncingis available.
Cheers,
M