Documentation/filesystems/dax.rst
Source file repositories/reference/linux-study-clean/Documentation/filesystems/dax.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/filesystems/dax.rst- Extension
.rst- Size
- 11405 bytes
- Lines
- 306
- 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.
- Touches user memory; correctness depends on fault-safe copying and privilege boundary handling.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
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
=======================
Direct Access for files
=======================
Motivation
----------
The page cache is usually used to buffer reads and writes to files.
It is also used to provide the pages which are mapped into userspace
by a call to mmap.
For block devices that are memory-like, the page cache pages would be
unnecessary copies of the original storage. The `DAX` code removes the
extra copy by performing reads and writes directly to the storage device.
For file mappings, the storage device is mapped directly into userspace.
Usage
-----
If you have a block device which supports `DAX`, you can make a filesystem
on it as usual. The `DAX` code currently only supports files with a block
size equal to your kernel's `PAGE_SIZE`, so you may need to specify a block
size when creating the filesystem.
Currently 5 filesystems support `DAX`: ext2, ext4, xfs, virtiofs and erofs.
Enabling `DAX` on them is different.
Enabling DAX on ext2 and erofs
------------------------------
When mounting the filesystem, use the ``-o dax`` option on the command line or
add 'dax' to the options in ``/etc/fstab``. This works to enable `DAX` on all files
within the filesystem. It is equivalent to the ``-o dax=always`` behavior below.
Enabling DAX on xfs and ext4
----------------------------
Summary
-------
1. There exists an in-kernel file access mode flag `S_DAX` that corresponds to
the statx flag `STATX_ATTR_DAX`. See the manpage for statx(2) for details
about this access mode.
2. There exists a persistent flag `FS_XFLAG_DAX` that can be applied to regular
files and directories. This advisory flag can be set or cleared at any
time, but doing so does not immediately affect the `S_DAX` state.
3. If the persistent `FS_XFLAG_DAX` flag is set on a directory, this flag will
be inherited by all regular files and subdirectories that are subsequently
created in this directory. Files and subdirectories that exist at the time
this flag is set or cleared on the parent directory are not modified by
this modification of the parent directory.
4. There exist dax mount options which can override `FS_XFLAG_DAX` in the
setting of the `S_DAX` flag. Given underlying storage which supports `DAX` the
following hold:
``-o dax=inode`` means "follow `FS_XFLAG_DAX`" and is the default.
``-o dax=never`` means "never set `S_DAX`, ignore `FS_XFLAG_DAX`."
``-o dax=always`` means "always set `S_DAX` ignore `FS_XFLAG_DAX`."
``-o dax`` is a legacy option which is an alias for ``dax=always``.
.. warning::
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
- This snippet crosses the user/kernel memory boundary; validate fault handling and access checks before translating the pattern.
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.