Atomic writes for ext4

Building on the discussion in the two previous sessions on untorn (or atomic) writes, for buffered I/O and for XFS using direct I/O, Ojaswin Mujoo remotely led a session on support for the feature on ext4. That took place in the combined storage and filesystem track at the 2025 Linux Storage, Filesystem, Memory Management, and BPF Summit. Part of the support for the feature is already in the upstream kernel, with more coming. But there are still some challenges that Mujoo wanted to discuss.

For ext4, a single filesystem block can be written atomically; that support was merged for 6.13, he said. There is work in progress on doing multi-block atomic writes in ext4. There are two main allocation challenges that need to be handled for multi-block, though: unaligned extents that do not match the hardware alignment requirements and ranges with mixed mappings, for example those that cover both unwritten data and hole sections.

The ext4 bigalloc feature eliminates the problem with unaligned extents because the cluster size for the filesystem can be set to, say, 16KB, so everything will be aligned on those boundaries. But it is a filesystem-wide setting, even if atomic writes are only needed for a few files, and it requires that any existing filesystem be reformatted to use the feature. Reformatting may not be desirable for all use cases, but multi-block writes with bigalloc is working now.

$ sudo subscribe today

Subscribe today and elevate your LWN privileges. You’ll have access to all of LWN’s high-quality articles as soon as they’re published, and help support LWN in the process. Act now and you can start with a free trial subscription.

Currently, without bigalloc, ext4 does not have a way to guarantee the needed alignment; if an atomic write is done on an unaligned extent, ext4 has no fallback, it simply returns an error to the user. In order to ensure the alignment, Mujoo is exploring a combination of extsize and forcealign. Extsize is a per-inode alignment "hint" to the allocator that is set with an ioctl() command; it will try to allocate all extents to the boundary specified, but can fail. The forcealign extended attribute can be set on a file that has an extsize specified in order to require that allocation alignment; it can be seen as a per-file bigalloc.

Luis Chamberlain said that he has done some analysis of ext4 using bigalloc with a 16KB cluster size and noticed that some writes are not aligned on 16KB boundaries; he wondered why that was. Ted Ts'o said that bigalloc guarantees that data blocks are aligned to the cluster size, but not metadata blocks, which are still 4KB-aligned. Journal updates, inode updates, and bitmap-allocation-block updates could all cause writes that are not aligned to the cluster size.

Chamberlain wondered if there was any way to support 16KB writes for ext4 metadata; Ts'o said that it would require ext4 support for filesystem block sizes larger than the page size. The buffered I/O path for ext4 would probably need to switch to using iomap, he said; the ext4 developers are interested in getting patches that make that switch and he understands that large-block-size support is fairly straightforward once that happens.

The idea is to not require any reformatting of the filesystem with extsize and forcealign, Mujoo said. That will require fallbacks for files that are not properly aligned when forcealign is set for them. A "compat" feature flag can be added that can be set on existing filesystems; that will allow older kernels to mount the filesystem. An ioctl() command can be added to fix files that are not properly aligned. The forcealign feature might also have use cases outside of atomic writes; for example, it might help with getting properly aligned blocks for use with a direct-access (DAX) filesystem.

The problem of mixed mappings affects both bigalloc and non-bigalloc ext4; avoiding atomic writes with mixed mappings should be the goal, but it may not always be met. If a mixed mapping is used for an atomic write, there are three solutions that he sees. The first is to return an error, which might be popular for those who do not want a fallback path. Another is to zero the holes and write them with the rest. Finally, ext4 can do something similar to what XFS is doing: write the data in a new place and atomically change the extent mappings. Ext4 has no infrastructure to support the XFS-like solution, however, so it would add complexity to the solution.

Mujoo described the roadmap for ext4 atomic-write support. The patch sets for multi-filesystem-block writes using bigalloc and for adding extsize and forcealign support to ext4 are being targeted for Linux 6.16. Subsequent features, including using extsize and forcealign for multi-block atomic writes, exploring an extent-swapping fallback, and enabling buffered atomic writes for ext4, will come later.

Chamberlain asked if the idea of using the multi-index feature of XArray had been evaluated as a means to more generically support atomic writes for all filesystems. Mujoo agreed that it would be nice to have VFS support for atomic writes that could be used by more filesystems, but has not really looked at that.