Linux下联合文件系统的研究及性能分析

　　摘要：该文通过分析Linux下现有联合文件系统实现，提取其特征，给出了联合文件系统的定义。归纳总结出基于VFS和基于底层文件系统两种联合文件系统设计模型。对联合文件系统的不同实现进行了测试比较和性能分析。

　　关键词：联合文件系统；虚拟文件系统；Unionmounts；Aufs；Unionfs；Unionfs-fuse

　　中图分类号：TP316文献标识码：A文章编号：1009-3044（2013）36-8315-06

　　Linux文件系统的用户视图是一个完整的层级目录树（HierarchicalDirectoryTree）.Linux通过虚拟文件系统（VFS，virtualfilesystemswitch）实现这种机制。VFS是一种面向对象的接口，具有多态性。上层系统调用可以通过这一虚拟接口驱动底层文件系统，包括各种磁盘文件系统和NFS。为了实现统一的名字空间，VFS隐藏了挂载节点下子目录树结构，替换以被挂载文件系统中的根目录[1]。

　　一些应用需要文件系统名字空间的层叠化特性支持。例如，嵌入式Linux测试开发过程中，开发者常常希望通过NFS更新开发板系统中的文件，同时也想保留针对每个开发板的测试配置信息和文件修改。支持这种特性的文件系统是联合文件系统（Unionfilesystem）。

　　本文对Linux下联合文件系统的设计进行深入研究。进行对比测试，分析了各实现之间性能差异和速度瓶颈，为联合文件系统过渡方案的选型和进一步研究开发提供参考。

　　1联合文件系统

　　SunOS下的TranslucentFilesystem（TFS）是早期的联合文件系统实现之一。设计的动机是提供文件系统级别的源代码版本控制[2]。

　　本文根据联合文件系统的设计动机和各种实现拥有的共同功能，对联合文件系统必须具备的特征进行如下描述[3-5]：

　　联合文件系统提供目前LinuxVFS还不具备的名字空间联合功能；

　　联合文件系统必须至少支持三层，其中最上层可读写（RW），其余各层只读（RO）；

　　联合文件系统可以修改系统调用语义，但必须保证修改后的语义符合POSIX标准。

　　1.1抽象特征和定义

　　联合文件系统本质上是一种能够对文件系统名字空间进行联合操作的抽象文件系统。文件系统的名字空间是文件路径名的集合。文件（绝对）路径名由根目录到文件的路径组成（如/usr/include/unistd.h）。文件路径名和文件系统管理的文件一一对应。

　　本文通过分析联合文件系统的实现，提取归纳出如下定义：

　　定义1分支（Branch）是要进行联合操作的底层文件系统，包括磁盘文件系统（disk-basedfilesystem）和网络文件系统（NFS）。

　　分支分为两类，一类是可读写分支，记作RW；一类是只读分支记作RO。该文限定联合文件系统只有最上层的分支可以为RW分支，其余分支均为RO分支。

　　定义2除白（Whiteout）是一种联合文件系统对象。在对文件进行删除操作后创建，以遮挡下层分支中的所有路径名相同的文件。

　　定义3不透明目录（Opaquedirectory）是一种带有不透明标记的目录。目录文件被删除，并重建后，将会被标记为不透明。不透明目录不会和下层分支中任何路径名相同的目录联合。

　　定义4令[Ans]和[Bns]为文件系统A和文件系统B的名字空间，A和B的名字空间联合操作记作[?*][?*]，用集合语言描述为：

　　[Ans?*Bns=Ans?Bns-Wns]（1）

　　其中，A是RW分支，B是RO分支，[Wns]是除白文件路径集。另外，对（1）式中读写性质作如下限定：A可只读（RO）或者读写（RW），B只读；若A为RW，B为RO，那么联合操作得到的文件系统可读写，否则，只读。

　　容易得到联合文件系统的递归定义：分支A覆盖在分支B上，B可以为另一RO联合文件系统。所以总是只有最上层分支具有RW属性。

　　在实际应用中，一些联合文件系统实现支持下层文件系统亦为RW，甚至支持分支的动态调整（比如，aufs支持动态插入删除分支到分支栈中）。这种动态特性增加了联合文件系统灵活性的同时也降低了联合文件系统的可靠性和稳定性。

　　POSIX标准定义的对文件和目录的典型操作在处理联合文件系统名字空间的时候，应该同时具有如下语义：

　　open（）：若以可写模式打开文件，包括O_WRONLY，O_RDWR，O_APPEND，如果路径名[α?Ans]，且[α∈Bns]，就将[α]对应的文件向上拷贝（copyup）到A中，并将[α]插入到集合[Ans]中。

　　readdir（）：返回[Ans?*Bns]。

　　unlink（）：如果路径名[α∈Ans]，从[Ans]中删除[α]；如果[α?Wns]将[α]插入到[Wns]中。

　　link（）：将路径名[β]添加到[Ans]中，如果[β∈Bns]，将[β]从[Wns]中删除。

　　其他文件相关系统调用对名字空间保持语义不变。注意，向[Ans]中添加路径名的时机由具体实现决定，且须具备写时拷贝（COW，copyonwrite）特性，以减少冗余，提高存储利用率。

　　本节从名字空间的角度提取了联合文件系统的抽象特征，并对一些重要概念进行了定义。接下来讨论具体的设计和实现。

　　1.2基于VFS的设计模型

　　VFS是实现文件系统抽象的核心，它提供了一个通用的文件系统模型，用以衔接各种底层文件系统。为增加文件系统的功能，同时避免直接修改久经考验的底层文件系统实现，提高文件系统代码的重用性和可靠性，一些联合文件系统实现选择基于VFS的设计模型。

　　图1基于VFS的设计模型

　　作为底层文件系统的抽象，VFS提供了一族数据结构来代表通用的文件对象。比如super_block，inode，dentry和file。另外，VFS还提供了两种数据结构管理文件系统的名字空间：structnamespace和structvfsmount。前者表示特定进程的名字空间，后者表示被挂载文件系统描述符。与传统Unix操作系统不同，Linux并不限制同一挂载点挂载文件系统的次数。并且所有的挂载信息都保存在由vfsmount作为基本元素的链表里面。这些信息是我们进行联合操作的基础。

　　所有和文件相关的系统调用都通过VFS提供的接口访问底层文件系统[1]。比如实现一个系统函数，需要读取目录文件，我们会调用vfs_readdir（），剩下对不同文件系统采取不同的操作就交给VFS完成。这种抽象接口机制提供给我们实现联合操作的时机。

　　1.3基于底层文件系统的设计模型