🙋 Frequently Asked Questions

🙋 Frequently Asked Questions#

Why are images packaged in EROFS larger than those with SquashFS?#

First of all, the initial target use cases of EROFS are high-performance embedded scenarios, such as smartphones powered by Android. Runtime performance is always the top priority for EROFS (or, systems and applications will be lagged), even if it means sacrificing some ultra-space savings to avoid significant performance regressions against uncompressed approaches.

However, EROFS has landed several new on-disk features to narrow the slight size difference with SquashFS or even outperform SquashFS. When comparing, please ensure the same configuration is used:

  • Compression algorithm (if data is compressed): EROFS uses LZ4 by default due to lowest decompression latencies among popular open-source algorithms, while SquashFS uses GZIP instead;

  • Compressed extent size: Almost all filesystems that natively support compression typically cut data into compressed extents for random access. EROFS focuses on smaller physical clusters to maximize random performance and use block-sized physical clusters by default (usually 4 KiB), whereas SquashFS uses 128 KiB. It can be adjusted using the -C option with mkfs.erofs.

Note

Large physical clusters (e.g., 1MiB) can significantly degrade random read performance as well as increase memory usage. Please conduct a thorough evaluation by factoring in the target image size prior to deployment.

  • Compression level: For example, EROFS uses LZ4HC_CLEVEL_DEFAULT (level 9) for LZ4 HC, whereas SquashFS often uses LZ4HC_CLEVEL_MAX (level 12);

  • Advanced features: Enable the -Efragments option for EROFS when comparing with SquashFS.

In addition, EROFS may produce larger images due to the following differences:

  • Inode size: Currently EROFS has to use 64-byte on-disk inodes (extended inodes) to support per-inode nanosecond timestamps, whereas SquashFS often uses 32-byte inodes with only 4-byte timestamps for regular files; Consider switching to 32-byte EROFS compact inodes (e.g., by using -T) if per-file timestamps are not a strong requirement;

  • Metadata compression: If your test sets contain a large number of files, EROFS may result in larger images compared to SquashFS if metadata compression is not enabled. Optional metadata compression has been supported since Linux 6.17; consider enabling it if metadata size is a concern.

  • File-based deduplication: SquashFS deduplicates files with identical data by default (it can be disabled with -no-duplicates), whereas EROFS does not (except for hardlinks). However, EROFS offers the similar functionality using -Efragments and even finer-grained data deduplication using -Ededupe.

  • BCJ filters: SquashFS can compress with XZ algorithm of BCJ enabled to optimize executable code. This feature is not supported by EROFS for now, but there are plans to introduce BCJ filters for all EROFS-supported algorithms.

Note that EROFS is still under active development. The features mentioned above are not top priorities at the moment due to limited development resources (anyway, SquashFS has existed for over 20 years) and target use scenarios, but they will be considered in the future, and contributions are always welcome. Again, note that SquashFS doesn’t always outperform EROFS in image size either. EROFS images are often significantly smaller (while still offering better runtime performance) when compressing files in small compressed extent sizes (especially smaller than 32KiB).

Additionally, EROFS has supported CDC-like compressed data deduplication since Linux 6.1, which also gives extra space savings (although -Ededupe is still single-threaded).

In brief, if image size is your top priority, please ensure that the options -Ededupe and -E(all-)fragments are specified with mkfs.erofs. At least, enable -Efragments to match the default configuration of SquashFS.

🚧 Under construction..#