So TIL Linux's ext4 fs driver in the default configuration imposes a bogus fsync on every atomic replace via rename.
Conversation
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...
1
1
...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.
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
Show replies