At least on Linux, this wouldn't be that ideal. These LWN articles go over the general fsync mess and the lack of viable alternatives:

> [...] most file systems take the brute force approach, with the result that fsync() commonly takes time proportional to all outstanding writes to the file system.

> So, now we have the following situation: fsync() is required to guarantee that file data is on stable storage, but it may perform arbitrarily poorly, depending on what other activity is going on in the file system.

> The problem is that filesystem developers are not willing to make much in the way of guarantees unless applications call fsync() [...] it is a "terrible answer" because it has impacts all over the system.

On Thu, Dec 24, 2020, 11:17 AM Michael A. Smith <> wrote:
With all the buffering that modern disks and filesystems do, a
specific question has come up a few times with respect to whether or
not data was actually written after flush. I think it would be pretty
useful for the standard library to have a variant in the io module
that would explicitly fsync on close.

You might be tempted to argue that this can be done very easily in
Python already, so why include it in the standard io module?

1. It seems to me that it would be better to do this in C, so for the
folks who need to make a consistency > performance kind of choice,
they don't have to sacrifice any additional performance.
2. Having it in the io library will call attention to this issue,
which I think is something a lot of folks don't consider. Assuming
that `close` or `flush` are sufficient for consistency has always been
wrong (at its limits), but it was less likely to be a stumbling block
in the past, when buffering was less aggressive and less layered and
the peak size and continuous-ness of data streams was a more niche
3. There are many ways to do this, and I think several of them could
be subtly incorrect. In other words, maybe it can't be done very
easily and correctly after all. Providing "obviously right" ways to do
things is the baileywick of the standard library, isn't it?

Thanks for your consideration and feedback,
Michael Smith
Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: