linux内核|盘点只读压缩文件系统

为什么需要只读压缩文件系统?
【linux内核|盘点只读压缩文件系统】在存储容量有限的嵌入式设备上 , 一般对于系统分区在使用过程中没有数据写入需求 , 同时希望可以节省存储空间——只读压缩文件系统应运而生 。 另外 , 只读压缩文件系统也可用于归档文件 。 相比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:00GMT 。 (最近访问过的文件可能会被更新时间戳 , 但只在内存中保存 。 )CramFS的镜像只支持被同样字节对齐方式的机器创建和挂载使用 , 页面大小只支持4KB 。
SquashFS的出现替代了CramFS , 但CramFS通过支持XIP(ExecutionInPlace)有了新的用武之地 。 SquashFS设计上相比CramFS去掉了大部分限制因素:其会保存完整的uid/gid(32位)、文件创建时间 , 单文件最大支持16EB , 文件系统最大大小也是16EB 。 压缩后的inode平均消耗8字节 , 根据文件类型不同(文件、目录、符号链接等)inode大小有所变化 。 对于压缩文件系统 , 压缩输入的数据块大小(chunksize)决定了压缩率收益和潜在的读放大开销 。 SquashFS2.x版本的chunksize最大为64KB , SquashFS3.x版本的chunksize最大可达1MB 。 SquashFS3.x版本默认的chunksize是128KB , 相比4KB大小的chunksize压缩率有明显提升 。 SquashFS还支持fragmentblock , 即多个小文件存入一个block , 极大的提升了压缩率 。 SquashFS支持大端和小端对齐方式 , 可以在不同的字节序机器上创建和挂载 。
CromFS的主要设计目标是高压缩率 , 性能和内存使用量不是它关心的方面 。 CromFS是一个用户态文件系统 , 通过块级别去冗和高压缩率算法实现压缩收益最大化 。 同CramFS和SquashFS的详细特性对比如下表:
linux内核|盘点只读压缩文件系统
文章图片
EROFS带来哪些新变化?
EROFS的全称是EnhancedRead-OnlyFileSystem , 相比前述只读压缩文件系统最大的不同是压缩思路和解压方式的改变 。 不同于以往固定输入长度(FixedSizedInput)的压缩形式 , EROFS采用固定输出长度(FixedSizedOutput)的压缩思路 。 这解决了固定输入长度的压缩带来的读放大问题 , 4KB的固定输出长度压缩就可达到128KB的固定输入长度压缩的压缩率 。 对于SquashFS来说 , 达到同样的压缩收益可能需要比EROFS多读几倍的数据块 。 另外 , SquashFS在运行时内存使用方面也远远多于EROFS的原地解压策略 , 这在系统处于低内存状态时会导致读性能大幅下降 。 为了更好的解压速度同时保证一定的压缩率 , EROFS使用的压缩算法为LZ4 。 默认压缩输出块大小为4KB , 其他特性支持上均对标SquashFS 。 这里不再一一赘述 。
定长输出和定长输入的示意如下图所示 , EROFS会通过多次尝试不同长度的输入数据将其压缩到固定大小(4KB)的输出块上 , SquashFS则是根据预先配置好的输入长度(ChunkSize)压缩数据并写到输出块上(可能跨多个数据块) 。 当EROFS的固定输出长度设为存储设备的块大小(如:4KB)时 , 可以认为没有读放大 。 因为无论要读的内容是哪一部分以及大小 , 对于块设备来说都至少要读取一个数据块 。


推荐阅读