[Python-Dev] Ext4 data loss

[Mikko Ohtamaa]

>
>
> > Ok. In that use case, however, it is completely irrelevant whether the
> > tempfile module calls fsync. After it has generated the non-conflicting
> > filename, it's done.
>
> I agree, but my comment was that it would be nice if better fsync
> support (if added) could be done in such a way that it helped not only
> file objects, but also *file-like* objects (such as the wrappers in the
> tempfile module) without making the file-like API any fatter.


fsync() might not be "the answer".

I found this blog post very entertaining to read:
http://www.advogato.org/person/mjg59/diary.html?start=195

"So, on the one hand, we're trying to use things like relatime to batch data
to reduce the amount of time a disk has to be spun up. And on the other
hand, we're moving to filesystems that require us to generate *more* io in
order to guarantee that our data hits disk, which is a guarantee we often
don't want anyway! Users will be fine with losing their most recent changes
to preferences if a machine crashes. They will not be fine with losing the
entirity of their preferences. Arguing that applications need to use *fsync*()
and are otherwise broken is ignoring the important difference between these
use cases. It's no longer going to be possible to spin down a disk when any
software is running at all, since otherwise it's probably going to write
something and then have to *fsync* it out of sheer paranoia that something
bad will happen. And then probably *fsync* the directory as well, because
what if someone writes an even more pathological filesystem. And the disks
sit there spinning gently and chitter away as they write tiny files[4] and
never spin down and the polar bears all drown in the bitter tears of
application developers who are forced to drink so much to forget that they
all die of acute liver failure by the age of 35 and where are we then oh yes
we're fucked."

-M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090316/a6bfe87a/attachment.htm>