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:
https://lwn.net/Articles/351422/ > [...] 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. https://lwn.net/Articles/788938/ > 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 <mich...@smith-li.com> 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 > concern. > 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 -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/UOUS4BNSI6WFBPWMXHJF5IEAV2PQ47VN/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2BIDNDQJSDX37G7E3UYEMSO2KOQJLHNI/ Code of Conduct: http://python.org/psf/codeofconduct/
