“好玩儿”文件系统大赏

Linux文件系统千千万，奇奇怪怪占一半。作为Unix/Linux操作系统的基本哲学之一，“一切皆文件”的设计思想产生了很多种不同的文件系统。有的文件系统并没有持久性的存储设备，比如：tmpfs，使用内存存储文件数据，重启后所有数据就烟消云散了。有的文件系统并不存储真实文件，比如：procfs、sysfs等，文件内容是进程、系统的一些控制和状态信息——读是获取状态，写就是控制状态。今天，我们来赏析几个看似中规中矩又“有点东西”的文件系统，看看它们有哪些不一样的思路（脑洞）。

OverylayFS

用途 ★★★★★

创意 ★★☆☆☆

OverlayFS ^[1] 允许将一个目录的内容（文件和目录）叠加到另一个目录上。源目录可以是不同的卷（分区），甚至可以是不同的文件系统。这创造了一个有趣的机制，允许临时修改只读文件和文件夹。一个简单的例子如下图所示：涉及两个目录，每个目录都包含文件和文件夹。我们可以把它们看作是“上层”和“下层”。“下层”目录仅可读取，OverlayFS提供了不同层的叠加视图，在“上层”目录不存在一个文件时默认到“下层”目录查找。请注意，Linux 内核仍然可直接访问两个原始目录（“上目录”和“下目录”），但通过OverlayFS访问时将无法修改“下层目录”。

图 1 OverlayFS示意图

对“上层”目录中的文件进行修改将照常进行，对“下层”文件夹中文件的任何修改都会在“上层”目录中创建一个副本，该文件将是修改后的文件。这样，“下层”文件将保持不变。删除操作如涉及“下层”中文件和目录，OverlayFS通过whiteouts和opaque directory机制实现了对“上层”的隐藏，真实文件和目录依然存在于“下层”。

OverlayFS最初的使用场景是使用Live CD启动的Linux系统——系统分区是只读的，通过OverlayFS可以实现对系统分区修改。这同样适用于Android开发场景，工程模式的版本同样有修改系统只读分区的需求。另外，OpenWRT也利用OverlayFS减少对低端闪存设备的擦写次数以避免寿命问题。OverlayFS最重头的应用是云平台中的容器镜像，基础的容器镜像通常不应被改变，新功能叠加可以通过OverlayFS实现且可以再次分发，基于新的镜像还可以继续使用OverlayFS叠加新的内容。OverlayFS简直就是为云容器应用打造的，也因此变得非常有用起来。

IncrementalFS

用途 ★★★☆☆

创意 ★★★☆☆

Incremental FS（IncFS）是谷歌在2019年提出的一个计划用于Android应用下载更新的文件系统^[2]。IncFS不允许直接写入文件，并且追加写后的内容也永不改变。它允许在大型Android应用程序的二进制文件和资源没有完全加载到Android设备上之前运行。如果应用读取的内容尚未加载，它需要等待数据块被提取，但是在大多数情况下是热块可以预先加载，并且应用程序几乎可以立即流畅运行。如下图所示，IncFS工作在其他文件系统之上（如：EXT4，F2FS），大部分操作可以透传给下层的文件系统。对于读操作如果需要的数据还没有完成加载，IncFS会通知上层应用等待直到超时，读到数据后需要进行校验；写操作需要记录数据块同时更新索引。数据块是被压缩存储的，在读的时候解压后返回给应用。读操作会被记录到日志文件，用于后续优化应用更新时数据块的下载顺序。

图2 IncFS介绍

IncFS可以为Android游戏/应用开发者提供快速调试和更新能力，更大的目标应该是为快应用（Instant App）提供了HTML 5之外的另一个解决方案。

ZoneFS

用途 ★★☆☆☆

创意 ★★★☆☆

介绍西部数据（WDC）开发的ZoneFS ^[3]之前，需要先提一下Zoned Block Device（分区块设备）。分区块设备是这样一类存储设备：地址空间分为多个区域，每个区域是一组连续的LBA。常规区类似于常规块设备，可以执行任何读取或写入访问。顺序区接受随机读取，但必须顺序写入。每个顺序区域都有一个由设备维护的写指针，该指针跟踪对设备的下一次写操作的强制起始LBA位置。由于该写限制，顺序区域中的LBA不能被覆盖。在重写之前，必须先使用特殊命令（区域复位）擦除顺序区域。分区存储的最常见形式是叠瓦式磁盘（Shingled Magnetic Recording）。

ZoneFS是一个非常简单的文件系统，将分区块设备的每个顺序区作为一个文件。与具有本机分区块设备支持（例如F2FS）的常规POSIX兼容文件系统不同，ZoneFS不会向用户隐藏分区块设备的顺序写入约束。因此ZoneFS本质上更接近原始块设备访问接口，而不是功能齐全的POSIX文件系统。

那这个看似“半残”的文件系统有什么用呢？一个用途是LevelDB这样的KV存储，可以将SSTables存储在顺序区文件中，在分区块设备上实现LSM Tree（Log Structured Merge Tree）结构。通过用文件API替换原始块设备文件访问，简化了应用程序中对分区块设备支持的实现，避免依赖直接的块设备文件ioctl。

LTFS（Linear Tape File System）

用途 ★★☆☆☆

创意 ★★★★☆

如果说ZoneFS是“半残”文件系统，LTFS ^[4]就有点“挑战不可能”的意思了。磁带数据存储已有50多年的历史，一直以来都没有属于自己的文件系统。因为磁带不适合进行非顺序读和一次性写以外的任何操作，一般用作数据归档。通常使用外部数据库维护文件元数据（文件名，时间戳，目录层次结构），但这些外部数据库通常不是为实现互操作性而设计的。所以用户没法在磁带机上浏览磁带存储上的数据，即使只是想找磁带上的一小部分数据也要拷贝这个磁带内容到电脑的磁盘上，然后配合外部数据库读取其中的文件。LTFS在磁带的头部存储整个磁带文件系统的元数据信息，通过加载这部分信息实现对磁带上文件的定位和读取。更厉害的是：LTFS支持对文件的修改，当然不是覆盖原来数据位置，而是在磁头当前位置写入新的内容。旧数据所占用的空间会被废弃，重新格式化文件系统前不能再写入别的数据。另外，LTFS也支持挂载多个磁带机甚至是跨网络形成统一的文件系统分区。

LTFS最初是由IBM在2008-2009年期间开发了LTFS的原型，在NAB 2009上进行了演示。基于该初始演示的反馈和经验IBM对文件系统进行了大修，最终作为产品发布。LTFS也号称再次焕发了磁带存储的生命力，让可以像U盘一样使用磁带。据说2025年将投入使用的欧洲最大天文望远镜会用到LTFS，每天存储PB级的新数据。

StegFS

用途 ★☆☆☆☆

创意 ★★★★★

StegFS是一种隐秘（Steganographic）文件系统，隐秘文件系统是由Ross Anderson等人^[5] 首先提出的一种文件系统。“隐秘”的含义可能比较难以理解，我们可以先从隐写术（Steganography）说起。隐写术是一门关于信息隐藏的技巧与科学，所谓信息隐藏指的是不让除预期的接收者之外的任何人知晓信息的传递事件或者信息的内容。这和加密是不同的，加密是通过算法对信息内容做明文到密文的变化，使得没有加密密钥的人无法获取明文内容。功能上看，隐写术在隐藏内容的基础上试图进一步隐藏数据的存在位置——让非信息接收者不知道信息的存在。一个基于图片的隐写如下图所示，a）是原图；b)是在图片数据上通过数学变换叠加了隐藏信息的图，肉眼根本无法区分；c)是通过工具将a) 和 b)做数学变化获得的隐藏内容。想尝试的同学可以试下BlindWaterMark这个工具。^[6]

图 3 隐写术在图片上的应用

StegFS就是在文件系统层面使用了隐写术的文件系统，分区上所有可用位置都被填入了随机加密数据，其中的文件数据都是加密后随机分布到分区上的。没有简便的方法来区分无意义的垃圾和隐写的数据，文件的位置是从文件的密钥派生而来的。这些位置是隐藏的，仅通过StegFS可读取。StegFS构建在EXT2之上，当StegFS未挂载时，这是一个普通的EXT2分区。所有隐写的文件都不可见，这导致了一个问题——普通文件可能会覆盖隐写文件。可以通过在多个位置写入文件以减少数据丢失的机会。当StegFS挂载时，会有一个stegfs目录出现在根目录，不同等级的隐写文件会出现在相应的子目录里。StegFS不会将解密的明文放在内存中，解密后的buffer会被新的数据内容覆盖。虽然性能变差但保证了机密性。StegFS并没有考虑进程隐藏的问题，这需要一些类似木马的实现方式。

总之，StegFS提供了一个对普通人似乎毫无用处的功能——让别人不知道你硬盘上存了些啥。相比加密的好处是，被抓起来找犯罪证据时你不会被严刑拷打逼问密码——因为看不到也无法分析出这些文件的存在，StegFS也不需要你的密码。除了StegFS的方式，基于图片和MP3等类型文件进行信息隐写也是常见的方法。

以上就是本文介绍的几个“好玩儿”的文件系统，当然“有意思的”文件系统不止这几个，比如：使用KV Store管理文件系统元数据提升小文件操作性能的TableFS ^[7]，几乎每年在FAST等学术会议上发表各种新改进的BetrFS（不是BtrFS哦）^[8]，使用Soft Updates技术 ^[9]保证文件系统一致性的FFS（Fast Filesystems），充分利用新型非易失存储、闪存和磁盘等设备的跨介质文件系统Strata FS ^[10]。感兴趣的同学可以自行学习（八卦）一下，给它们的创意评评分。

参考文献：

[1]  OverlayFS介绍，https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html

[2] Paul Lawrence, Incremental Filesystem, LPC 20, https://linuxplumbersconf.org/event/7/contributions/784/attachments/522/934/Incremental_FS_for_LPC2020.pdf

[3] ZoneFS介绍，https://www.kernel.org/doc/html/latest/filesystems/zonefs.html

[4] LTFS资料, https://www.lto.org/linear-tape-file-system/

[5] Anderson et.al, The Steganographic File System, https://www.cl.cam.ac.uk/~rja14/Papers/stego-fs.pdf

[6] BlindWaterMark代码, https://github.com/chishaxie/BlindWaterMark

[7] Ren et.al, TABLEFS: Enhancing Metadata Efficiency in the Local File System, ATC 2013

[8] BetrFS网站，https://www.betrfs.org/

[9] G. R. Ganger et.al, Soft updates: a solution to the metadata update problem in file systems. ACM Transactions on Computer Systems (TOCS), 18(2):127–153, 2000

[10] Kwon et.al, Strata: A Cross Media File System, FAST 2017

长按关注

内核工匠微信

Linux 内核黑科技 | 技术文章 | 精选教程