Understanding EROFS: A Read‑Only Linux File System for Immutable Deployments

Overview

EROFS (Enhanced Read‑Only File System) merged into Linux 5.4 LTS in 2019, is supported by mainstream distributions and Alibaba Cloud Linux kernels 4.19, 5.10, and 6.6. It is used as the root file system in Android 13, AWS Bottlerocket, AWS Attestable AMIs, Fedora 42+ Live CD, and other platforms.

Container ecosystem support

Containerd 2.1 includes an EROFS snapshotter. ComposeFS stores its metadata in EROFS. Dragonfly Nydus RAFS v6 uses an EROFS‑compatible metadata format. The package‑bundle format Ruyi Linglong uses EROFS as its bundle format. Sandbox engines that adopt EROFS include Kata containers, Nerdbox, gVisor, OpenEuler Conch, and Tencent Cloud Agent Runtime. RHEL 10 officially supports EROFS and deprecates SquashFS.

Problem addressed

Generic file systems such as EXT4 and XFS carry metadata‑inconsistency risks when untrusted images are mounted in shared‑kernel container environments. Their reliance on journaling and pre‑mount fsck checks is costly and insecure for immutable workloads.

Design principles

EROFS employs a strict fixed‑block‑size layout; all file data must be block‑aligned, enabling direct DMA transfers on block devices and PAGE‑size alignment for memory‑mapped files. Metadata is minimal, eliminating redundant inode tables and allowing on‑the‑fly content‑addressable storage.

Optional features:

Native compression (LZ4, LZMA, Zstandard, DEFLATE).

Rolling‑hash deduplication (CDC).

Metadata compression for massive small‑file workloads.

The layered design supports both block‑diff and file‑diff mechanisms. File diffs are self‑contained, allowing independent intermediate layers such as GPU drivers.

Runtime enhancements

Linux 6.12+ and Alibaba Cloud Linux 5.10/6.6 allow direct mounting of EROFS image files without a loop device. Fanotify‑based lazy loading replaces virtual block devices. Host‑side page‑cache sharing across image mounts yields 4 %–47 % memory‑reuse gains. FSDAX passthrough enables guest VMs to access data without a page cache.

Performance evaluation

Unpack time comparisons (local image repository) show:

x86 (m7i): EXT4 11.11 s → EROFS 6.72 s (‑39.5 %).

ARM (m7g): EXT4 9.73 s → EROFS 6.00 s (‑38.3 %).

NVIDIA (g4dn): EXT4 23.56 s → EROFS 17.03 s (‑27.7 %).

Typical use cases

Since Containerd 2.1, the EROFS snapshotter can transparently convert OCI images to EROFS format, accelerating container startup, reducing storage, and guaranteeing data persistence with fsync(2) (avoiding the heavier syncfs(2) required by OverlayFS). Containerd 2.3 will natively pull and run EROFS images, further shortening startup time.

EROFS also serves as the immutable root file system for platforms such as AWS Bottlerocket and Android 13.

References

Official documentation: https://erofs.docs.kernel.org

Containerd EROFS snapshotter documentation: https://github.com/containerd/containerd/blob/v2.3.0-beta.0/docs/snapshotters/erofs.md

Additional relevant links:

LWN article on direct image mounting: https://lwn.net/Articles/990750

LWN article on fanotify lazy loading: https://lwn.net/Articles/1055062

Containerd release notes: https://github.com/containerd/containerd/releases/tag/v2.1.0

ComposeFS repository: https://github.com/composefs/composefs

Kata containers pull request: https://github.com/kata-containers/kata-containers/pull/11172