为什么需要只读压缩文件系统？

在存储容量有限的嵌入式设备上，一般对于系统分区在使用过程中没有数据写入需求，同时希望可以节省存储空间——只读压缩文件系统应运而生。另外，只读压缩文件系统也可用于归档文件。相比tar，zip等压缩软件，只读压缩文件系统的性能和灵活性都更好。Linux早期的只读文件系统有CramFS和SquashFS，以及参考了上述两个文件系统设计的用户态只读压缩文件系统CromFS。另外，最近两年在Android平台上实现商用的EROFS也值得关注。EROFS针对手机使用场景，对读放大和内存占用过多从设计理念上带来了一些新的优化。

CramFS，SquashFS，CromFS横评

CramFS被设计成用于存储空间很小的嵌入式设备上，倾向于极致简单、极其节省空间。在使用上存在诸多限制，如：单个文件大小不能超过16MB、文件系统大小略大于256MB（最后一个文件允许超过256MB空间范围，即文件系统总大小不超过272MB）。CramFS的gid只保存8位，mkcramfs会简单的将gid截断保留最后8位（有一些安全风险）。CramFS支持硬链接，但是被硬链接的文件引用计数不会增加。CramFS文件没有时间戳，所有文件的创建/访问时间戳都是1970年1月1日 0:00:00 GMT。（最近访问过的文件可能会被更新时间戳，但只在内存中保存。）CramFS的镜像只支持被同样字节对齐方式的机器创建和挂载使用，页面大小只支持4KB。

SquashFS的出现替代了CramFS，但CramFS通过支持XIP（Execution In Place）有了新的用武之地。SquashFS设计上相比CramFS去掉了大部分限制因素：其会保存完整的uid/gid（32位）、文件创建时间，单文件最大支持16 EB，文件系统最大大小也是16 EB。压缩后的inode平均消耗8字节，根据文件类型不同（文件、目录、符号链接等）inode大小有所变化。对于压缩文件系统，压缩输入的数据块大小（chunk size）决定了压缩率收益和潜在的读放大开销。SquashFS 2.x版本的chunk size最大为64KB， SquashFS 3.x版本的chunk size最大可达1MB。SquashFS 3.x版本默认的chunk size是128KB，相比4KB大小的chunk size压缩率有明显提升。SquashFS还支持fragment block，即多个小文件存入一个block，极大的提升了压缩率。SquashFS支持大端和小端对齐方式，可以在不同的字节序机器上创建和挂载。

CromFS的主要设计目标是高压缩率，性能和内存使用量不是它关心的方面。CromFS是一个用户态文件系统，通过块级别去冗和高压缩率算法实现压缩收益最大化。同CramFS和SquashFS的详细特性对比如下表：

表1 CramFS，SquashFS，CromFS对比

EROFS带来哪些新变化？

EROFS的全称是Enhanced Read-Only File System，相比前述只读压缩文件系统最大的不同是压缩思路和解压方式的改变。不同于以往固定输入长度（Fixed Sized Input）的压缩形式，EROFS采用固定输出长度（Fixed Sized Output）的压缩思路。这解决了固定输入长度的压缩带来的读放大问题，4KB的固定输出长度压缩就可达到128KB的固定输入长度压缩的压缩率。对于SquashFS来说，达到同样的压缩收益可能需要比EROFS多读几倍的数据块。另外，SquashFS在运行时内存使用方面也远远多于EROFS的原地解压策略，这在系统处于低内存状态时会导致读性能大幅下降。为了更好的解压速度同时保证一定的压缩率，EROFS使用的压缩算法为LZ4。默认压缩输出块大小为4KB，其他特性支持上均对标SquashFS。这里不再一一赘述。

定长输出和定长输入的示意如下图所示，EROFS会通过多次尝试不同长度的输入数据将其压缩到固定大小（4KB）的输出块上，SquashFS则是根据预先配置好的输入长度（Chunk Size）压缩数据并写到输出块上（可能跨多个数据块）。当EROFS的固定输出长度设为存储设备的块大小（如：4KB）时，可以认为没有读放大。因为无论要读的内容是哪一部分以及大小，对于块设备来说都至少要读取一个数据块。

图 1 定长输出和定长输入的区别

在内存分配上，EROFS根据上层希望读取的内容是否需要将盘上读出数据全部解压会选择不同的策略。对于需全部解压的情况，EROFS会使用VFS已分配的Page Cache内存页，这样节省了内存的占用；对于需部分解压的情况，EROFS则会独立分配缓存页以便后续读取相同压缩块时避免产生新的I/O。当压缩数据块已被读入内存后，以下图中读取数据块3，4为例，EROFS的基本数据解压方式大致步骤如下：

1) 根据上层要读取范围计算要解压的数据块（这个例子中是0，1，2，3，4）

2) 分配临时缓存页（可选）存放解压内容（0，1，2），VFS已分配数据页不用再分配

3) 通过vmap将上述物理页映射为连续虚拟页

4) 如果有原地I/O占用了VFS分配的数据页，则将数据拷贝到临时页

5) 解压数据到指定虚拟地址

图 2 EROFS压缩和解压示意图

为优化内存占用，EROFS还提供了缓存解压/滚动解压（预分配一定数量的内存页）、原地解压等策略。另外，通过调度优化和协同解压进一步改善了数据读取性能。理论上，解压的过程增加了CPU计算时间，而压缩数据读取减少了I/O时间（特别是对于顺序读取来说）。所以对于只读压缩文件来说，压缩率达到一定收益后读性能会好于不压缩的文件系统。即CPU时间的增加小于I/O时间的减少，这从EROFS的测试数据也可以看出：当压缩节省空间超过35%以上时，随压缩比提升EROFS的读性能（特别是顺序读）会越来越好于EXT4。

以上就是对只读压缩文件系统的一个简单介绍，可以看出根据应用场景的不同各个只读压缩文件系统在压缩比、压缩/解压效率上各有侧重。EROFS相比其他只读压缩文件系统引入了更多的设计思路，实现细节和一些优化值得肯定。

参考文献：

[1]  Gao et. al., EROFS: A Compression-friendly Readonly File System for Resource-scarce Devices, ATC 2019

[2] SquashFS, https://zh.wikipedia.org/wiki/SquashFS

[3] CromFS, https://bisqwit.iki.fi/source/cromfs.html

[4] SquashFS HOWTO, https://tldp.org/HOWTO/SquashFS-HOWTO/whatis.html

[5] CramFS, https://www.kernel.org/doc/html/latest/filesystems/cramfs.html