EROFS in 2026: When a Read-Only Filesystem Beats SquashFS (Performance, Dedupe, Updates)

SquashFS has been the default read-only compressed filesystem for embedded Linux for over a decade. EROFS (Enhanced Read-Only File System) is now a serious alternative, having matured in the mainline kernel since Linux 5.4. In specific workloads—particularly random reads, container images, and systems with dm-verity—EROFS outperforms SquashFS by a meaningful margin.

Design philosophy differences

SquashFS was designed for maximum compression. It uses large block sizes (up to 1 MB by default) and compresses aggressively. This produces the smallest possible images but means that reading a single small file may require decompressing an entire 128 KB or larger block.

EROFS was designed for performance-first read-only storage. It uses fixed-size output blocks (matching the page size, typically 4 KB) and compresses data in page-aligned chunks. This means random reads decompress only the pages actually needed, resulting in lower latency and less memory pressure.

Benchmark comparison

Measured on a Cortex-A53 (1.5 GHz) with eMMC 5.1 storage, running Linux 6.6:

The random read performance difference is the headline number. EROFS delivers 3x the random read IOPS because it decompresses at page granularity instead of block granularity. For systems running applications that make many small reads (config files, shared libraries, locale data), this translates directly to faster application startup.

Compression options

SquashFS

SquashFS supports gzip, lz4, lzo, xz, and zstd. For embedded systems:

• lz4 for speed-sensitive systems (fastest decompression)
• zstd for the best balance of compression ratio and speed
• xz for maximum compression when read speed is not critical

EROFS

EROFS supports lz4, lz4hc, lzma, and deflate. The compression is applied per-block (4 KB aligned), so the compressor's per-block efficiency matters more than its streaming performance.

• lz4 for minimum decompression latency
• lz4hc for better compression with lz4 decompression speed (recommended default)

EROFS also supports a "micro-lzma" mode for very small files, achieving xz-level compression ratios for metadata-heavy filesystems.

Deduplication

EROFS has native block-level deduplication support (added in Linux 6.1). Identical 4 KB blocks are stored once and referenced from multiple locations. This is particularly valuable for:

• Container images where many layers share common files
• Multi-configuration builds where variants share most of their filesystem
• Systems with many similar configuration files

SquashFS handles deduplication at the file level through fragment blocks (tail-end packing) but does not perform block-level deduplication across different files.

For a rootfs with significant file duplication (common in Yocto-generated images with multiple package variants), EROFS deduplication can reduce image size by 5–15% beyond compression alone.

dm-verity integration

Both filesystems work with dm-verity for integrity verification. However, EROFS's page-aligned blocks mean that dm-verity hash tree lookups align naturally with the filesystem's read patterns. SquashFS's variable-size compressed blocks can cause hash tree reads for blocks that span multiple dm-verity data blocks.

In practice, this means EROFS + dm-verity has lower verification overhead than SquashFS + dm-verity, particularly for random read workloads.

The dm-verity guide covers the setup for both filesystems.

OTA update considerations

Read-only filesystem images are replaced atomically during updates. The relevant factor is image size (affects download time and flash wear) and whether delta updates are practical.

SquashFS images are difficult to delta-update because compression is applied across large blocks. A small file change can alter a significant portion of the compressed output.

EROFS's fixed-size output blocks make delta updates more practical. A tool like bsdiff or a block-based delta mechanism can identify changed 4 KB blocks and produce compact deltas. The OTA update tooling covers integration with RAUC and SWUpdate.

Tooling

Creating SquashFS images

mksquashfs rootfs/ rootfs.squashfs -comp zstd -Xcompression-level 15 -b 131072

SquashFS tools are mature and widely available in distribution packages.

Creating EROFS images

mkfs.erofs -zlz4hc rootfs.erofs rootfs/

EROFS tools (erofs-utils) are packaged in most distributions since 2023. The mkfs.erofs tool supports all compression options and deduplication.

When to choose which

Choose SquashFS when:

• Maximum compression ratio is the priority (xz compression)
• Your workload is primarily sequential reads (streaming media, log playback)
• You need compatibility with older kernels (pre-5.4)
• Your existing build pipeline is built around SquashFS tooling

Choose EROFS when:

• Random read performance matters (application startup, shared library loading)
• You use dm-verity and want lower verification overhead
• Block-level deduplication would reduce your image size
• You want more practical delta updates
• Memory pressure is a concern (lower cache footprint)

Migration from SquashFS to EROFS

Switching filesystems in an existing product:

1. Update the build pipeline to produce EROFS images (replace mksquashfs with mkfs.erofs)
2. Ensure the target kernel has EROFS support compiled in (CONFIG_EROFS_FS=y)
3. Update mount commands in initramfs or fstab
4. Regenerate dm-verity hash trees for the new image format
5. Test thoroughly—file permissions, symlinks, device nodes, and xattr must be preserved

The filesystem content is identical; only the on-disk format changes. Applications are unaware of the underlying filesystem.

Integration with ProteanOS

ProteanOS build outputs can use either filesystem format. The ProKit build configuration includes a ROOTFS_FORMAT option that selects between SquashFS and EROFS. Hash tree generation for dm-verity is handled automatically based on the selected format.

Summary

EROFS has earned its place alongside SquashFS in the embedded Linux toolkit. For 2026, the recommendation is straightforward: if your workload involves significant random reads, use dm-verity, or benefits from deduplication, EROFS is the better choice. If maximum compression is paramount and reads are sequential, SquashFS remains effective. Both are mature, mainline, and well-supported.