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

[Ian Charnas]

OK I finished a patch that exposes os.fullfsync on platforms that
support it, and I added the corresponding documentation in
Doc/library/os.rst

Any comments?

http://bugs.python.org/issue3517

-ian

On Thu, Aug 7, 2008 at 10:17 AM, Ian Charnas <ian.charnas at gmail.com> wrote:
> 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
>>
>