The feature is called auto_da_alloc, and the documented purpose is correct - ensuring that, *if* the rename is seen after async power failure, the data in the new file is also seen. But then it goes and does more...
Conversation
...which is wrong. It makes the whole rename syscall sleep until the data is committed, as if it were rename+fsync. Which makes sense if you cared about the data, but then you would have called fsync yourself!
2
1
1
Replying to
So the ultimate desired behaviour would be:
- Once rename() returns, new is replaced with old for the running system (in-memory)
- Some time after rename() is called, new is fsynced then replaces old on disk (if a restart happens)
The in-between time sounds scary to me?
2
No, to do a transaction safely, you need to fsync the file to commit the data to storage, rename it and then fsync the containing directory to commit the transaction. By covering up the problem, ext4 is hurting performance while the bugs in software are still present and serious.
1
1
Aha, so you can fsync the containing directory to ensure rename is stable on disk?
1
Yes, that's the way to do it as an atomic transaction where either the previous data or the new data is guaranteed to be intact. Since many developers got it wrong and continue to get it wrong the ext4 developers hard-wired hacks to work around broken code at the expense of perf.
1
Not every use of a rename pattern like this cares about having a fully atomic transaction. It's nasty to have detection of common patterns in the kernel with workarounds. It reminds me of the Windows approach to compatibility. There are some other nasty hacks like this in Linux.
1
The hack often doesn't solve the issue because it only works for a single file and programs doing this wrong often need to commit a transaction across multiple files. The way to do that correctly a symlink to a directory and renaming the symlink to a new (committed) directory.
1
One of the main issues in this area is that developers don't want to pay the cost of using fsync properly so it isn't used nearly as much as it should be and filesystem developers have not appropriately prioritized optimizing it. There are also examples of bad code overusing it.
1
For example, Firefox has historically overused tiny SQLite transactions by committing every single change immediately, including doing commits with every letter that's typed in the address bar. They liked to blame SQLite when SQLite was doing exactly what they asked correctly.
1
twitter.com/DanielMicay/st
Also, to clarify, you can safely leave out the final directory fsync as long as it's okay for either the previous version or the new version to be present after a crash / power loss. The fsync (or fdatasync) or the file data is what's needed for that.
Quote Tweet
Replying to @mik235 and @RichFelker
No, to do a transaction safely, you need to fsync the file to commit the data to storage, rename it and then fsync the containing directory to commit the transaction. By covering up the problem, ext4 is hurting performance while the bugs in software are still present and serious.
My understanding is that with data=ordered or at least with data=journal, just journaling should get you this either-or property with no fsync or fdatasync whatsoever. Is that wrong?
1
You definitely do need fdatasync, but fdatasync is traditionally a very fast operation compared to fsync. It's true that on ext3, data=ordered worked as you described, but there's no guarantee of that kind of coarse journal and ext4 changed this with delayed allocation of blocks.
1
Show replies