Documentation/filesystems/ext4/atomic_writes.rst
Source file repositories/reference/linux-study-clean/Documentation/filesystems/ext4/atomic_writes.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/filesystems/ext4/atomic_writes.rst- Extension
.rst- Size
- 9806 bytes
- Lines
- 226
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
.. _atomic_writes:
Atomic Block Writes
-------------------------
Introduction
~~~~~~~~~~~~
Atomic (untorn) block writes ensure that either the entire write is committed
to disk or none of it is. This prevents "torn writes" during power loss or
system crashes. The ext4 filesystem supports atomic writes (only with Direct
I/O) on regular files with extents, provided the underlying storage device
supports hardware atomic writes. This is supported in the following two ways:
1. **Single-fsblock Atomic Writes**:
EXT4 supports atomic write operations with a single filesystem block since
v6.13. In this the atomic write unit minimum and maximum sizes are both set
to filesystem blocksize.
e.g. doing atomic write of 16KB with 16KB filesystem blocksize on 64KB
pagesize system is possible.
2. **Multi-fsblock Atomic Writes with Bigalloc**:
EXT4 now also supports atomic writes spanning multiple filesystem blocks
using a feature known as bigalloc. The atomic write unit's minimum and
maximum sizes are determined by the filesystem block size and cluster size,
based on the underlying device’s supported atomic write unit limits.
Requirements
~~~~~~~~~~~~
Basic requirements for atomic writes in ext4:
1. The extents feature must be enabled (default for ext4)
2. The underlying block device must support atomic writes
3. For single-fsblock atomic writes:
1. A filesystem with appropriate block size (up to the page size)
4. For multi-fsblock atomic writes:
1. The bigalloc feature must be enabled
2. The cluster size must be appropriately configured
NOTE: EXT4 does not support software or COW based atomic write, which means
atomic writes on ext4 are only supported if underlying storage device supports
it.
Multi-fsblock Implementation Details
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The bigalloc feature changes ext4 to allocate in units of multiple filesystem
blocks, also known as clusters. With bigalloc each bit within block bitmap
represents a cluster (power of 2 number of blocks) rather than individual
filesystem blocks.
EXT4 supports multi-fsblock atomic writes with bigalloc, subject to the
following constraints. The minimum atomic write size is the larger of the fs
block size and the minimum hardware atomic write unit; and the maximum atomic
write size is smaller of the bigalloc cluster size and the maximum hardware
atomic write unit. Bigalloc ensures that all allocations are aligned to the
cluster size, which satisfies the LBA alignment requirements of the hardware
device if the start of the partition/logical volume is itself aligned correctly.
Here is the block allocation strategy in bigalloc for atomic writes:
* For regions with fully mapped extents, no additional work is needed
* For append writes, a new mapped extent is allocated
* For regions that are entirely holes, unwritten extent is created
* For large unwritten extents, the extent gets split into two unwritten
extents of appropriate requested size
* For mixed mapping regions (combinations of holes, unwritten extents, or
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.