⚖️ Features and Comparison

Note that it’s just an incomplete list for the qualitative evaluation. The overall purpose of this is to show EROFS benefits compared to other in-kernel approaches when making technical decisions.

Feature (as of Linux 6.6)	EROFS	EXT4	SquashFS
Minimal block size	512 B [1]	1 KiB	Unaligned[2]
Inode size	32/64 B	128/256 B	Varied [3]
Limitation of total UIDs/GIDs	No	No	Yes (64k)[4]
Pre-1970 / ns timestamps	Yes	Yes	No
Filesystem UUID	Yes	Yes	No
Filesystem label (Volume label)	Yes	Yes	No
Inline data	Yes	Yes	No
Data compression	Yes [5]	No	Yes
Largest compression granularity	1 MiB	N/A	1 MiB
Default compression granularity	1 Block [6]	N/A	128 KiB
Fragments	Yes	N/A	Yes
Metadata compression	No [7]	N/A	Yes
Multiple compression algorithms	Per-file	N/A	No
Data deduplication	Extent-based	No? [8]	No
Extended attribute support	Yes	Yes	Yes
File-based distribution	Yes	No	No
External data (multi-devices)	Yes	No	No
POSIX.1e ACL support	Yes	Yes	No
Direct I/O support [9]	Yes	Yes	No
FIEMAP support	Yes	Yes	No
FSDAX support	Yes	Yes	No
Large folio support [10]	Yes	No	No

---

[1]

512-byte blocks can be used for tarball data reference.

[2]

It means a fixed minimal filesystem I/O size which SquashFS doesn’t have. Instead, SquashFS has its own “block size”: its compressed files are split up in fixed-size blocks. See Squashfs Binary Format/About.

[3]

SquashFS has different on-disk inodes for each type of varying contents and size. See Squashfs Binary Format/Inode Table.

[4]

SquashFS allows 32-bit UIDs/GIDs, but only among 2¹⁶ unique values. See Squashfs Binary Format/Inode Table.

[5]

Data compression is an optional feature of the EROFS filesystem. Currently, the supported compression algorithms include LZ4, MicroLZMA (since Linux 5.16), and DEFLATE (since Linux 6.6 LTS).

[6]

The default block size of EROFS is 4 KiB on x86 and x86-64.

[7]

EROFS metadata is designed to be directly accessible without decoding or deserialization (e.g., protobuf) since they could cause I/O amplification and extra runtime overhead in resource-limited scenarios.

[8]

Strictly speaking, EXT4 has a feature named “shared_blocks”, which will prevents applications from writing to the filesystem.

[9]

For example, direct I/O can be used for loop devices backed by unencoded files on the EROFS filesystem to avoid double caching. Direct I/O on encoded files is almost useless since it should not do ANY caching and thus will kill the overall performance.

[10]

EROFS supports large folios for uncompressed files since Linux 6.2.