https://bugzilla.kernel.org/show_bug.cgi?id=70121 --- Comment #7 from Theodore Tso <tytso@xxxxxxx> --- On Fri, Mar 07, 2014 at 07:16:40AM +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > > How does the file system know that the file has "successfully been > > written"? Secondly, even if we did know, in order to guarantee the > > transaction semantics, we *always* update the journal first. Only > > after the journals is updated, do we write back to the final location > > on disk. So what you are suggesting just simply wouldn't work. > > It seems it is just a too major change. Maybe it is something that could be > considered in ext5. If you think it can be done, plesae submit patches. :-) > > it just > > makes it more likely, but if you crash at the wrong moment, you can > > still lose data > > > I have never seen a damaged file with full data journaling enabled. Can you > show me a race condition so that I can reproduce it? Hm, maybe it would be > possible if the journal is smaller than the file (I'm wondering what would > happen in such a case). If the application is in the middle of writing the file when the journal is committing, the file can be half written at the point where the system is rebooted. If you are thinking about the case where the application writes to a temp file, and then renames the temp file on top of the pre-existing file (without first fsync'ing the temp file, which is the application bug), then yes, data journalling will save you from that one particular use case, but it will come at a cost. (And if you crash while you are writing the temp file, of course you do lose your pending changes.) You can get the same level of protection by using mount -o nodelalloc instead of mount -o data=journal. As I said before, you'll give up some performance, but it won't be as bad as using data=journal --- and you should still file bug reports with your applications so they use fsync() properly. I'll note that if they don't, you'll have problems with all other file systems, whether they be xfs, btrfs, etc. Fsync(2) is the *only* way you can guarantee that the contents of a file which has been written is safely on stable store. - Ted -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
