[Python-Dev] small PATCH to fix os.fsync on OS X

[Ian Charnas]

Excellent comments, everyone.  It looks like I didn't know the full
situation, thanks scott for pointing me towards that email on
darwin-dev.   The email said that fsync on OS X does indeed force a
flush from the operating system to the hard drive (so my earlier
understanding was incorrect), but data could still be waiting in the
write buffer of the physical hard drive, so OS X provides a
"fullfsync" feature to force the disk to flush its buffers.  So far
they are seemingly the only unix to provide this.

So, I think we should cancel the ticket I made in Roundup, and I'd
like to make another patch that exposes os.fullfsync on platforms that
support it, just like we already have os.fdatasync on supported
platforms.

That way, os.fsync remains untouched, and people wishing to get at
fullfsync may do so.

comments?  Should I go ahead and make this patch?

many thanks,
-Ian Charnas

On Thu, Aug 7, 2008 at 9:48 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> I can't think of a situation where it would be useful to do an fsync()
>> in which you don't want the data to be flushed as far as possible.
>
> Essentially, you are saying that you don't see a use for fsync. If
> that's the case, then this API should be removed from Python completely.
>
> As all others have said: the strong feature of the posix module is that
> it exposes the operating system calls *as-is*, i.e. without trying to
> tweak their semantics.
>
> If Apple had found it as a useful default for fsync to have the
> harddisk flushed, they would have put that into the implementation
> of fsync, instead of coming up with a new API. We don't second-guess
> operating system vendors (normally).
>
> Please understand the enormous relevance of this strategy. If we
> deviate from it, people might be stuck in chasing the culprit,
> complaining alternatingly to the OS vendor and to Python. With our
> strategy to the POSIX module, we can always defer people to the
> system vendor, and they can easily reproduce the behavior with
> a C program. (Of course, we also have higher-layer libbraries, were
> any bugs are our own).
>
> Regards,
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ian.charnas%40gmail.com
>