Operations 10 min read

Read-only Compressed File Systems: CramFS, SquashFS, CromFS, and EROFS Comparison

Read‑only compressed file systems such as CramFS, SquashFS, CromFS, and the newer EROFS provide space‑saving, non‑writable storage for embedded devices, with CramFS limited by small file and filesystem sizes, SquashFS offering large limits and flexible chunking, CromFS focusing on maximal compression, and EROFS improving performance and memory usage through fixed‑output LZ4 compression and in‑place decompression.

OPPO Kernel Craftsman
OPPO Kernel Craftsman
OPPO Kernel Craftsman
Read-only Compressed File Systems: CramFS, SquashFS, CromFS, and EROFS Comparison

Read-only compressed file systems emerge as a solution for embedded devices with limited storage capacity, where system partitions have no data writing requirements during operation and storage space needs to be conserved. These file systems can also be used for archiving. Compared to compression tools like tar and zip, read-only compressed file systems offer better performance and flexibility.

CramFS, SquashFS, and CromFS Comparison

CramFS was designed for embedded devices with minimal storage space, prioritizing extreme simplicity and space efficiency. However, it has several limitations: single file size cannot exceed 16MB, filesystem size is slightly over 256MB (with the last file allowed to exceed the 256MB boundary, making total filesystem size up to 272MB). CramFS stores only 8 bits for gid, creating potential security risks. It supports hard links but reference counting doesn't increase for linked files. Files have no timestamps - all creation/access times are set to January 1, 1970 0:00:00 GMT. CramFS images can only be created and mounted on machines with the same byte alignment, with only 4KB page size supported.

SquashFS replaced CramFS and addresses most of its limitations. It stores complete uid/gid (32 bits) and file creation times, supports maximum single file size of 16 EB and filesystem size of 16 EB. Compressed inodes average 8 bytes. For compression filesystems, the chunk size determines compression ratio benefits and potential read amplification overhead. SquashFS 2.x supports maximum chunk size of 64KB, while SquashFS 3.x supports up to 1MB (default is 128KB). SquashFS also supports fragment blocks, storing multiple small files in one block to improve compression ratio. It supports both big-endian and little-endian alignment, allowing creation and mounting on different byte-order machines.

CromFS's main design goal is high compression ratio, with less focus on performance and memory usage. As a user-space filesystem, it achieves maximum compression through block-level deduplication and high-compression algorithms.

EROFS: New Innovations

EROFS (Enhanced Read-Only File System) differs from previous read-only compressed file systems primarily in its compression approach and decompression method. Unlike the traditional fixed-sized input compression, EROFS uses fixed-sized output compression. This solves the read amplification problem inherent in fixed input length compression - 4KB fixed output compression can achieve compression ratios comparable to 128KB fixed input compression. For SquashFS, achieving the same compression benefits may require reading several times more data blocks. Additionally, SquashFS uses significantly more memory during runtime compared to EROFS's in-place decompression strategy, which can cause major performance degradation under low memory conditions.

EROFS uses the LZ4 compression algorithm for better decompression speed while maintaining reasonable compression ratio. The default compressed output block size is 4KB. When the fixed output length is set to the storage device's block size (e.g., 4KB), there is essentially no read amplification, as reading any portion of content requires at least one data block from the block device anyway.

For memory allocation, EROFS chooses different strategies based on whether the data read from disk needs full decompression. For cases requiring full decompression, EROFS uses VFS-allocated Page Cache memory pages, saving memory; for partial decompression cases, EROFS independently allocates cache pages to avoid new I/O when reading the same compressed block again.

The basic decompression steps in EROFS include: calculating which data blocks need decompression based on the read range, optionally allocating temporary cache pages for decompressed content, using vmap to map physical pages to contiguous virtual pages, copying data to temporary pages if in-place I/O occupies VFS-allocated data pages, and decompressing data to the specified virtual address.

EROFS also provides strategies for optimizing memory usage including cached decompression and rolling decompression (pre-allocating a certain number of memory pages), as well as in-place decompression. Additionally, scheduling optimization and cooperative decompression further improve data read performance.

Theoretically, decompression increases CPU computation time while compressed data reading reduces I/O time (especially for sequential reads). Therefore, for read-only compressed file systems, once compression reaches a certain level, read performance becomes better than uncompressed filesystems - the increase in CPU time is less than the decrease in I/O time. This is confirmed by EROFS test data: when compression saves more than 35% space, EROFS read performance (especially sequential read) improves progressively compared to EXT4 as the compression ratio increases.

Embedded SystemsEROFSLinux filesystemcompressed filesystemcompression algorithmLZ4read-only file systemSquashFS
OPPO Kernel Craftsman
Written by

OPPO Kernel Craftsman

Sharing Linux kernel-related cutting-edge technology, technical articles, technical news, and curated tutorials

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.