Linux atomic writes: untorn does not mean durable

Three questions, not one guarantee

Linux RWF_ATOMIC requests protection against power loss or hardware failure leaving mixed old and new contents in the affected range. Its scope is one supported pwritev2() operation, not an arbitrary application transaction. [1]

O_DIRECT concerns the data-transfer path; it does not supply the synchronization guarantees of O_SYNC. On successful synchronized-I/O completion, O_DSYNC covers data and metadata needed to retrieve it; O_SYNC also covers other associated file metadata. Select the completion contract separately. [3]

Names add another boundary. Synchronizing file contents does not necessarily persist a changed directory entry; that requires a separate directory synchronization on Linux. A protected data range is not a durable filename replacement. [5] See the directory durability analysis.

For a database page, write down the promised recovery state before selecting flags. "No mixture" can still allow the complete previous page; "committed" must match the application's persistence and recovery protocol.

Ask the file, not the product label

Request STATX_WRITE_ATOMIC and inspect the returned stx_mask. For attributes, use stx_attributes_mask before interpreting STATX_ATTR_WRITE_ATOMIC. A requested bit is not proof of support. The reported minimum/maximum units are byte sizes; stx_atomic_write_segments_max limits the vector count. [2]

Direct-I/O memory and offset alignment are separate constraints, queryable through STATX_DIOALIGN where supported. Do not infer them from an advertised sector size alone. [3]

For the documented interface, use direct I/O, a power-of-two total length within the reported bounds, an offset divisible by that length, and no more than the reported number of vectors. [1]

A supported maximum is not an optimized maximum. stx_atomic_write_unit_max_opt, when nonzero, identifies an optimized upper size; zero means to use the supported maximum. A larger supported request is not invalid merely because it exceeds the optimized size, but may be slower. [2]

A block-aligned offset can still be wrong

These are synthetic examples, not measurements: assume a 4 KiB minimum, 64 KiB supported maximum, 16 KiB optimized maximum and one vector. The arithmetic uses bytes; 1 KiB is 1,024 bytes. "Fits" means only that these three geometry checks pass. It does not verify capability, buffer alignment, direct-I/O flags or durability.

The third row is the useful trap: 4 KiB alignment is insufficient for this 16 KiB request. Splitting a larger update into independently protected writes would also change the recovery contract: it would not establish one all-or-nothing update across those operations.

The filesystem is part of the contract

Ext4 documents hardware-backed atomic writes for extent-based regular files using direct I/O. Single-filesystem-block support and multi-block support are different configurations; the latter uses bigalloc and is bounded by cluster and device limits. Ext4 does not document a software or copy-on-write fallback for this feature. [4]

Mixed mapped and unwritten regions require extra preparation: the documented implementation arranges a contiguous backing extent and consistent allocation metadata before issuing the protected data write. This explains why a drive's capability alone cannot describe a filesystem operation. It is not a latency benchmark. [4]

A different contract: AdvFS at FAST '15

Verma and colleagues described an O_ATOMIC interface in AdvFS, using hidden writable clones and copy-on-write to preserve a synchronized file version. Their syncv mechanism grouped multiple files by journaling clone-deletion metadata. This is a filesystem recovery protocol, not another name for Linux RWF_ATOMIC. [6, sections 3 and 3.1]

The paper explicitly excludes overlapping or concurrent modifications through multiple file descriptors from its guarantee. Its implementation and failure-injection results are historical evidence, not a test of today's Linux atomic-write interface or proof of current AdvFS availability. We did not reproduce those experiments. [6]

Our synthesis: identify the protected range, commit boundary and concurrency rules separately. Individually untorn pages do not make a multi-page update failure-atomic. Compare WAL and page recovery and the crash-test oracle before replacing an existing recovery mechanism.

A review checklist before changing a storage engine

1. Record the actual kernel, filesystem, mount configuration and storage stack. Query the intended file and preserve the returned capability masks and limits.
2. Validate request and buffer constraints, then check the operation's actual return value. Do not silently substitute an ordinary write when protection is required.
3. Choose and check the required synchronization boundary before acknowledging a durable application commit.
4. Define a recovery oracle for an isolated test environment, including failures before acknowledgement and dependencies between records. Geometry tests cannot replace crash testing.

This checklist is Hesela's engineering synthesis, not a certified implementation. No hardware interruption, filesystem experiment or performance measurement was performed. The model deliberately excludes device behavior, mapping changes, overlapping writers, metadata transactions and persistence. Support must be established on the deployed stack.

Corpus: torn write, RWF_ATOMIC, STATX_WRITE_ATOMIC. Related: failed synchronization and RAID write-hole protection.

Primary sources

1. Linux man-pages, readv(2): pwritev2 and RWF_ATOMIC.
2. Linux man-pages, statx(2): atomic-write fields and returned masks.
3. Linux man-pages, open(2): O_DIRECT, O_DSYNC and O_SYNC.
4. Linux kernel documentation: ext4 Atomic Block Writes, requirements and implementation.
5. Linux man-pages, fsync(2): file synchronization and directory entries.
6. Verma et al. (2015), Failure-Atomic Updates of Application Data in a Linux File System. FAST 15, pp. 203-211; sections 3-4.

Reviewed 12 October 2026. Documentation describes an interface, not proof of support on every Linux installation.