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

　　在向内核添加新功能的时候，如无需对内核数据结构进行修改，将新功能编译成内核模块有很多好处。至少我们可以将联合文件系统的代码和内核其他代码分离开来，这种松耦合可以降低相互影响，减小引入bug的几率。VFS对于整个内核文件子系统十分重要，所有底层文件系统，包括磁盘文件系统和NFS都依赖于VFS对上层系统调用提供服务。避免对VFS直接修改，将联合文件系统作为一种底层文件系统来设计就是基于底层文件系统的设计模型。这种设计模型对VFS模拟底层文件系统接口，对真正的底层文件系统提供VFS接口。

　　这种设计模型消除了基于VFS的设计模型必须修改内核数据结构，必须静态链接的弊端，降低了耦合度，但也因此引入了一些缺陷，比如重复设置与VFS类似的数据结构，浪费内存空间；复杂化了内核函数调用关系。

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

　　基于底层文件系统的设计模型目前有三种较为成熟的实现：aufs，unionfs和unionfs-fuse。该文接下来分别讨论。

　　1.4.1Aufs

　　Aufs最大的特点就是支持的功能多，甚至可以在多可写层之间，根据存储空间状态进行负载均衡。缺点是实现复杂[4]。

　　Aufs在RW分支自动创建三种辅助对象：WhiteoutBase，伪链接目录，Step-Parent目录。Aufs删除文件会在RW分支创建除白，除白是一个普通文件（.wh.），为节省inode，会被链接到WhiteoutBase。伪链接目录维持unlink（）的语义，比如f1，f2均在某一RO层，指向同一inode，如果f1被向上拷贝到RW层，f1对应inode被修改，然后被unlink（），f2指向伪链接获得修改后的内容。Step-Parent目录是为了向上拷贝后文件所在目录被删除这种情况下保持unlink（）语义。另外，aufs采用的除白算法造成名字空间污染是不可避免的，如果采取unionmounts的做法，将除白作为拓展属性实现，用户空间的一些实用程序就需要进行修改，它们无法自动识别这种属性的。所以aufs开发者采用了类似unionfs的做法。

　　图3aufs分支合并

　　系统调用readdir（）通过虚拟目录实现，aufs可以选择在内核空间或者用户空间生成虚拟目录，虚拟目录就是自动计算合并分支之后的目录，获得个分支上的目录信息通过模拟VFS，调用vfs_readdir（）实现。

　　1.4.2Unionfs

　　Unionfs作为FiST的子项目开发。FiST是一套文件系统模板开发语言，用于降低可堆叠文件系统的开发难度，提高可移植性[6]。FiST所产生的可堆叠文件系统在功能上，等价于BSD的stackingvnode。所以unionfs在功能上等价于BSD的unionmounts。不过，FiST生成的可堆叠文件系统不是通过改变VFS数据结构实现，而是基于底层文件系统实现。unionfs独立于VFS，提供了VFS和底层文件系统的中间层抽象。

　　Unlink（）在unionfs采用”deleteall”策略，即尽量删除所有RW分支中的同名文件，减少冗余。然后在尽可能低优先级的RW分支中创建除白。这种策略的缺点是，除白有可能分散在所有分支中，如果以后分支再单独挂载，名字空间的污染也会扩散影响到这些分支。

　　1.4.3Unionfs-fuse

　　Unionfs-fuse完全在用户空间实现，基于FUSE技术。如图4，FUSE技术简化了文件系统开发难度，本身作为一种底层文件系统实现，将操作请求发送给用户空间文件系统。用户空间文件系统例如Unionfs-fuse可以使用任何用户空间能够是使用的机制，甚至再次使用文件相关系统调用，请求VFS访问Ext3。最后将结果按原路径返回。FUSE适合基于低速设备的低利用率文件系统[7]。

　　图4Unionfs-fuse访问请求

　　Unionfs-fuse继承了FUSE的优点和缺点。整体上设计简单，使用方便。缺点是性能差，稳定性不好，函数调用路径长，内核态用户态切换频繁，浪费处理器时间。另外，由于逻辑简单，且在用户空间实现，无法保持一些系统调用的POSIX语义。Unionfs-fuse对名字空间的污染相对其他实现比较小。

　　2性能测试与比较

　　我们对联合文件系统主流实现进行了性能测试，并结合设计模型和具体实现策略分析比较测试结果，指出性能瓶颈。由于Linux下unionmounts还出于开发阶段。重构之前的版本最高支持内核版本2.6.36，不具有可比性。该文只针对实际可用的实现进行测试。测试的实现包括：aufs（3.2），unionfs（2.5.11）和unionfs-fuse（0.26，fuse2.9.2）。该文用ext3表示用户视图相同的磁盘文件系统。

　　2.1测试方法

　　测试硬件环境为Corei5-3210M，4Gram。测试软件环境为Linux3.2.2（x86），本文进一步将处理器核心数设定为1，将内存设定为512M，以减少CPU部件复用和磁盘缓存对实验结果的影响。

　　根据典型应用配置，我们测试包含三层分支的联合文件系统。分别记：最上层br0（RW），次上层br1（RO），最下层br2（RO）。分支文件系统采用Ext3。

　　测试分为两部分：

　　整体测试。使用bonnie++（1.03e）工具，对文件顺序块读写，常用文件操作进行测试[8]。测试数据由程序随机生成。注意，整体测试只是对文件系统最基本的操作进行测试，不针对特定文件系统，所以我们用关键系统调用测试作以补充。另外，关键系统调用测试中的元数据操作针对性更强，对单个系统调用参考价值更高。

　　关键系统调用测试。该文使用自制的测试程序，对关键系统调用进行测试。根据各个系统调用的具体特性：readdir（）在联合文件系统中实现最复杂，经常成为性能瓶颈；stat（）直接相关路径查找操作；对除白和不透明目录的处理依赖unlink（）和rmdir（）。决定单独测试这四个系统调用[9]。我们的测试程序读入计算好的文件列表，避免测试时调用额外的readdir（），将unlink（）和rmdir（）放在一起测试，删除整个文件列表中的文件。

　　图5关键系统调用测试文件系统配置

　　我们使用Linux内核git仓库生成数据集，每个仓库65918个文件。用户视图中共5个仓库，329590个文件，共11.5GB。如图5所示，每个分支存储三个仓库，相邻分支重叠两个仓库。

　　2.2测试数据

　　整体测试结果：

　　表1整体测试结果（数据读写）

　　[＼&写入（KB/s）＼&读取（KB/s）＼&aufs＼&76461＼&86309＼&unionfs＼&76821＼&85710＼&unionfs-fuse＼&75887＼&73340＼&ext3＼&79761＼&87313＼&]

　　表2整体测试结果（元数据处理）

　　[＼&顺序创建＼&顺序访问＼&顺序删除＼&aufs＼&474.87＼&+++＼&726.04＼&unionfs＼&528.64＼&+++＼&970.61＼&unionfs-fuse＼&524.52＼&+++＼&839.11＼&ext3＼&1106.12＼&+++＼&1554.54＼&]

　　注：表中数值为每秒中处理文件个数与CPU占用率之比，越大越好，+++表示测试在500ms内完成，无法准确测试结果。

　　关键系统调用测试结果：

　　表3关键系统调用测试（Warmcache）单位：秒

　　[＼&stat（）＼&readdir（）＼&unlink（）/rmdir（）＼&aufs＼&76.512389＼&0.182901＼&139.194497＼&unionfs＼&105.276759＼&0.509551＼&120.132527＼&unionfs-fuse＼&51.912848＼&3.184761＼&174.321461＼&ext3＼&0.896848＼&0.227560＼&110.855304＼&]

　　表4关键系统调用测试（Coldcache）单位：秒

　　[＼&stat（）＼&readdir（）＼&aufs＼&69.792664＼&45.461619＼&unionfs＼&107.774489＼&64.861283＼&unionfs-fuse＼&51.054629＼&64.416526＼&ext3＼&46.510049＼&23.932659＼&]

　　2.3数据分析与比较

　　如表1所示，顺序块读写测试中磁盘IO是性能瓶颈，内核态联合文件系统对磁盘IO影响不大。Aufs/unionfs重复设置inode，dentry等VFS对象，一次间接调用变成两次，所以写性能分别下降4.14%和3.69%，读性能分别下降1.15%和1.84%。Unionfs-fuse内核态/用户态切换带来的额外开销导致写，读性能分别下降4.86%和16%。表2显示联合文件系统元数据处理开销显著，在整体测试中，bonnie++并不针对联合文件系统，所有测试数据在br0上生成和删除，没有除白和不透明目录产生。在用户视图相同的条件下，定义性能保持度如下：

　　定义5性能保持度=联合文件系统性能/底层文件系统（ext3）性能*100%。

　　图6整体测试元数据操作性能保持度

　　Unionfs元数据处理系统调用（creat（），stat（）等）复杂度适中，又处于内核空间，所以性能保持度最高。unionfs-fuse虽然属于用户空间文件系统，但是实现简单所以相对功能复杂的aufs，反而在处理元数据的时候开销更小。测试中，我们设定的文件数是51200，三种实现均能在500ms内完成顺序访问。值得注意的是，bonnie++的顺序访问是stat（）和readdir（）两个系统调用的混合操作，测试结果同时说明，这两个系统调用一般应用场景，绝对性能损失非常小。