Following widespread complaints, ext4 gained a crash-safety guarantee called
auto_da_alloc which is enabled by default. What about other filesystems? Out of the most well-known filesystems, which of them provide this same guarantee (and which of them do not)?
Personally I am interested in hearing information about
- XFS - Red Hat Enterprise Linux default filesystem.
- btrfs - SuSE Enterprise default filesystem.
- bcachefs - out-of-tree Linux filesystem, derived from bcache. "The COW filesystem for Linux that won't eat your data."
This issue mostly concerns Linux, as per the history below. It would be interesting to know how ZFS behaves as well, but I tend to assume it wouldn't implement this.
fsync() is well-documented as the correct way to write file data e.g. when you hit "save" in a text editor. And it is widely understood that e.g. text editors must replace existing files atomically using rename(). This is meant to protect against loss of power, making sure that you always either keep the old file, or get the new file (which was fsync()ed before the rename). You don't want to be left with only a half-written version of the new file.
But there was a problem that calling fsync() on ext3, which was the most popular Linux filesystem, could effectively leave the whole system hanging for tens of seconds. Since applications can do nothing about this, it was very common to optimistically use rename() without fsync(). That pattern seemed to work rather well on this filesystem, even if the system lost power.
Therefore, applications exist which do not use fsync() correctly.
The next version of the filesystem, ext4, generally avoided the fsync() hang. At the same time, it started relying much more on the correct use of fsync().
This is all pretty bad. Understanding this history is arguably not helped by dismissive phrases used by many of the conflicting kernel developers.
This was resolved in ext4, to
support the rename() pattern without requiring fsync() for crash-safety provide behaviour in a crash as the old ext3 filesystem did. This behaviour can be disabled again if you mount with the option