| |||||||||||||
Ts'o: Delayed allocation and the zero-length file problemTs'o: Delayed allocation and the zero-length file problemPosted Mar 19, 2009 19:34 UTC (Thu) by anton (guest, #25547)In reply to: Ts'o: Delayed allocation and the zero-length file problem by drag Parent article: Ts'o: Delayed allocation and the zero-length file problem
But as it's pointed out that many applications do get it right consistantly. Vim, OpenOffice, Emacs, mail clients, databases, etc etc. All sorts of them. Right?Emacs did get it right when UFS lost my file that I had just written out from emacs, as well as the autosave file. But UFS got it wrong, just as ext4 gets it wrong now. There may be applications that manage to work around the most crash-vulnerable file systems in many cases, but that does not mean that the file system has sensible crash consistency guarantees.
(Log in to post comments)
Ts'o: Delayed allocation and the zero-length file problem Posted Mar 19, 2009 19:50 UTC (Thu) by alexl (subscriber, #19068) [Link]
That is true, and I "fixed" the glib saver code to also fsync() before rename in the case where the rename would replace an existing file.
However, all apps doing such syncing results in lower overall system performance than if the system could guarantee data-before-metadata on rename. So, ideally we would either want a new call to use instead of fsync, or a way to tell if the guarantees are met so that we don't have to fsync.
|
|||||||||||||