基于闪存特性的EXT4文件系统读写性能优化研究

，

(西安邮电大学 计算机学院，西安 710061)

0 引言

Android是一款基于Linux内核的开源操作系统，一经提出便在移动设备上迅速普及，目前Android系统已经占据了全球智能手机五成份额[1]。Android智能手机广泛使用体积小、功耗低的eMMC(Embedded Multi Media Card)作为数据存储设备，区别于传统机械硬盘，eMMC使用闪存芯片作为存储介质[2]。同时因手机电源不稳定的特点，Android默认使用EXT4文件系统[3]，作为Linux中最常用的日志文件系统，采用JBD2(Journal Block Device 2)软件[4]进行日志记录，因此拥有良好的故障恢复能力，能够保证Android系统的稳定性以及数据的安全性。目前Android存储系统架构与Linux存储系统架构类似，有着用户空间与内核空间两部分。内核空间中主要包括EXT4文件系统与eMMC存储设备两个部分，EXT4文件系统通过虚拟文件系统向用户空间提供系统调用接口，而EXT4文件系统底层则通过通用块层、块设备驱动层与eMMC块设备关联起来[5]。

目前针对Android系统存储性能优化的方案主要有两个方面：一方面是用户空间中对应用软件或者软件依赖运行库的优化；另一方面是内核空间中对文件系统的优化。用户空间中的优化主要集中于对Android中大量使用的SQLite数据库技术的改进，例如通过消除SQLite的WAL模式下数据库checkpoints的写冗余部分，获取存储性能的提升[6]，但是这样的方案只能够提升软件利用SQLite技术存储数据时的存储效率，无法对Android系统中文本文件、多媒体文件等多种类型的文件读写产生有效提升。内核空间中的优化主要包括对Android默认使用的EXT4文件系统的优化以及针对Android使用的闪存设备设计专门的文件系统两种方案，前者优化调整EXT4文件系统中的重要参数从而提升文件系统的整体存储性能，但是方案中并没有考虑到EXT4文件系统的日志功能用于闪存设备所造成的影响，而且效果并不理想[7]；后者则有着著名的F2FS(Flash Friendly File System)[8]，此方案虽然在小文件的随机读写上有着较大的提升，但是由于开发时间尚短，在系统稳定性、软件兼容性等方面仍无法与EXT4文件系统相比，因此目前尚未广泛使用。

针对Android智能手机普遍采用的eMMC存储设备挂载EXT4文件系统的存储系统架构，本文分析了EXT4文件系统日志特性导致其对闪存设备文件读写性能衰减的问题，提出了一种能够消除此问题的EXT4文件系统日志功能优化方案。

1 相关理论

1.1 EXT4日志文件系统

EXT4文件系统借用了数据库中事务的思想，为需同步至磁盘的数据建立相关的日志数据，以便能够在发生系统崩溃后可以利用日志数据恢复，重新使文件系统保持一致的状态[9]。EXT4文件系统挂载时将磁盘空间划出一小块空间作为日志数据区域，专门用于存储日志数据。文件系统读写文件时，保持原有的读写磁盘逻辑不变，通过JBD2进程将影响文件系统一致性的元数据块及时写入到日志数据区域中。

表1 EXT4文件系统数据同步事务状态表

图1描述了EXT4文件系统日志数据流。虚线箭头表示了当文件系统读写数据中途崩溃时的修复过程，重新挂载分区时根据日志数据区域中的数据，逐一将记录下的元数据写回到磁盘原始位置，保证文件系统的一致性。实线箭头表示每次EXT4文件系统读写磁盘时的逻辑，首先由JBD2进程将每次需要写入的数据中元数据部分拷贝一份，将元数据封装成日志数据后提交到日志数据区域，之后EXT4文件系统对磁盘进行正常读写数据流程，这样的一次流程被称为一次事务。表1为一个事务几种状态的描述[10]，以区分事务的执行程度。

图1 EXT4文件系统日志数据流图

EXT4的日志数据区域以文件系统的块为单位组织日志数据，有着类似于通用数据区域的结构划分，但是相比通用数据区域更加简单，起始位置存放了日志数据的超级块，用于组织管理日志数据区域，随后便是按顺序以及一定规则存放的各次事务日志数据。一次事务的日志数据主要由描述块、数据块和提交块组成，其中描述块标识了一份日志数据的起始位置，数据块则存储了日志数据内容，提交块用于表明本次事务是一次完整的事务，在文件系统崩溃恢复时只会使用完整的事务数据。在进行文件系统崩溃恢复时，需要找到日志数据的数据块所在原文件系统的块地址进行回写修复，因此日志数据中的各个数据块与原文件系统的目标块的对应关系就尤为重要，这种对应关系存放在描述块中。由于数据块数量不定，JBD2在描述块中通过一个数据结构表明一组对应关系，该数据结构为：

typedef struct journal_block_tag_s

{

__be32 t_blocknr;

__be32 t_flags;

__be32 t_blocknr_high;

} journal_block_tag_t;

该结构体通过其在描述块中序号标识代表的数据块号，通过t_blocknr字段标识对应的原文件系统块地址。每个描述块中都包含了一个或多个journal_block_tag_t结构体用于表明本次事务日志数据中各数据块对应的文件系统原始位置。

1.2 闪存转换层

闪存转换层(Flash Translation Layer，简称FTL)是一种通过块设备模拟方式实现闪存设备存储系统的技术。将底层NAND闪存介质的管理及操作封装起来，为文件系统提供块设备读写接口，从而让文件系统访问NAND型闪存就像访问传统机械硬盘一样[11]。闪存转换层的功能主要有两点：地址映射及垃圾回收。一般情况下，闪存转换层通过维护两个静态表来完成它的功能[12]，如图2所示。

图2 闪存转换层结构图

闪存转换层通过其内部维护的地址映射表和空间管理表来管理逻辑地址转换以及闪存的物理空间。当文件系统通过块设备读写接口读写块设备时，由闪存设备接收对逻辑区块地址的读写请求，根据读写请求中的逻辑区块地址，在闪存转换层中通过地址映射表找到对应的物理区块地址进行访问，这就是闪存转换层的地址映射功能。垃圾回收即对闪存中的无用数据进行回收，闪存转换层指定一个闪存块进行垃圾回收，通过空间管理表中的页面状态判断当前页中的数据是否需要保留，对需要保留的数据页(Live，页面状态中记录了物理页面对应的逻辑区块地址)暂时拷贝至缓存或其他区域，等待块擦除完成再次写入原位置，对于处于已经无用的数据页面(页面状态为dead)则无需拷贝，直接擦除[13]。

2 EXT4文件系统闪存设备的性能衰减分析

EXT4文件系统挂载时对块设备划分的日志数据区域是对逻辑区块地址的划分，即针对闪存转换层维护的地址映射表中逻辑区块地址进行了通用数据区域与日志数据区域的划分。但是当实际数据同步至闪存设备时，逻辑区块地址实际映射的闪存物理地址是根据闪存设备自身损耗均衡等机制确定并建立映射的，这样就会导致在EXT4文件系统提出IO请求的逻辑区块地址上，通用数据与日志数据严格分离，但是在闪存设备中，两种数据却可能是混杂在同一个闪存块中的。

如图3所示，日志数据区域是逻辑区块地址范围为100至149的区域，当EXT4文件系统开始将数据同步至闪存设备时，文件数据写入到通用数据区域，而日志数据写入到日志数据区域，两个区域都是连续且严格分离的，但是数据写入到闪存设备具体页时，数据会由闪存设备根据自身的策略选择一个空白页进行写入，这就导致了在一个闪存设备的物理块中，日志数据的页与通用数据的页是混杂的。

图3 通用数据及日志数据存储状况

EXT4文件系统通过JBD2将日志数据提交到日志数据区域，JBD2软件通过函数jbd2_journal_next_lob_block函数获取下一个可写入的逻辑区块地址，此函数的实现决定了日志数据以何种顺序记录在日志数据区域中。 jbd2_journal_next_log_block函数中由j_head变量作为日志数据区域的写指针，用于指向下一个可写的逻辑区块地址，在每次写入一个逻辑块后通过自增的方式改变写指针位置。当指针指向日志数据区域尾部即日志数据区域全部写满后，指针会重新指向日志数据区域头部，即日志数据再次从区域头部开始写入。采用这样方式能够利用传统机械硬盘的可覆写特性，不对以往写入的日志数据执行删除操作，直接覆盖写入新的日志数据。如图4所示。

图4 JBD2日志数据区域循环结构原理

根据以上情况可以看出，EXT4文件系统可以在日志数据区域不断的循环写入日志数据，在满足日志数据写指针到达日志数据区域尾部之前，日志数据不会主动删除，对于闪存设备而言，这些数据随机分散在闪存设备的各个块中，并且与通用数据混杂在一起，闪存设备进行垃圾回收时，这些数据所在页的状态仍为Live，导致闪存设备垃圾回收时仍然需要拷贝这部分无用日志数据，造成文件系统读写闪存文件性能衰减的现象，本文对此问题提出相应解决方案。

3 优化方案

本文针对以上描述的问题，提出主动删除事务日志数据策略，根据EXT4文件系统数据同步事务处于Finished状态时，通用数据以及日志数据已经全部写入磁盘的含义，结合JBD2日志数据区域循环结构的特性，在事务状态变为Finished时记录本次事务日志数据的结束逻辑区块地址，多次数据同步事务的过程中，通过上次事务与本次事务保存下来的逻辑区块地址确定本次事务的日志数据位置，进行主动删除操作。对于开启日志功能的EXT4文件系统，优化后单次数据同步操作的基本流程如图5所示。

图5 优化后EXT4单次数据同步事务流程

通过多次数据同步事务中对图5中描述的流程不断循环，达到及时删除无用日志数据的目的，消除因日志功能导致的EXT4文件系统读写性能衰减问题。根据事务的Finished状态记录下本次事务日志数据的结束逻辑区块地址，同时检查是否存在有效的上次事务日志数据的结束逻辑区块地址，若存在，则两地址之间的页保存了本次事务的日志数据，将这段逻辑区域地址对应的闪存物理页面无效化，从而将日志数据删除；若不存在，则不进行闪存页面无效化操作，本次事务保存的地址在下次事务时标记了日志数据的起始区块地址，从而实现下次事务的日志数据删除操作。

图6 主动删除事务日志数据策略原理

如图6所示，在日志数据区域中,事务日志数据的主动删除策略通过j_invalid_begin与j_invalid_end两个变量记录事务日志数据的逻辑区块地址，将日志数据删除，完成后将j_invalid_end向后移动，作为下次删除操作的起始位置。当日志数据的删除指针到达日志数据区域尾部时，采取与日志循环写入结构相同的策略，删除指针重新指向日志数据区域头部。

本文为EXT4文件系统的日志功能实现了一个额外的循环结构，将不会再被使用到的日志数据删除，无用的日志数据基于事务Finished状态进行删除，Finished状态即表示正式数据已经写入完毕，不再需要该事务的日志数据预防宕机、EXT4文件系统崩溃等情况，因此不会出现有用的日志数据被删除的情况，保证系统稳定性的同时提高文件系统读写性能。

4 实验分析

4.1 实验环境

为验证本文提出的EXT4文件系统日志功能优化方案，进行实机测试比较，所用机型为Samsung Galaxy S5，具体环境参数如表2所示。

表2 测试环境

对Linux内核修改后编译并移植至测试机器中，进行相应测试。

4.2 测试分析

首先通过A1 SD Bench进行测试，这是一款Android手机存储性能测试工具，能够测试手机内置闪存、RAM等设备的性能。执行50次A1 SD Bench闪存性能测试，每次分别进行100秒读取及写入操作，统计读取与写入的数据量计算出对闪存读取速度与写入速度。如图7、8所示，图中横坐标为测试次数序号，纵坐标为读、写速度。

通过图7可以看到，灰色线条表示优化前读取速度折线图，黑色线条则表示优化后读取速度。优化前EXT4读取速度范围约为166.6 Mb/s至181.3 Mb/s，而优化后读取速度范围约为187.4 Mb/s至199.8 Mb/s，虽然速度存在一定波动，但是从图中可以看出，优化后的读取速度相比优化前有着明显的提升。

图7 优化前后读取速度比较

图8 优化前后写入速度比较

通过图8可以看到，与读取速度类似，写入速度也存在波动的现象，优化前的EXT4写入速度范围约为20.2 Mb/s至22.2 Mb/s，优化后的写入速度范围约为22.6 Mb/s至24.63 Mb/s。虽然优化前写入速度最大值与优化后写入速度的最小值之间的差距并不大，甚至在第18次的测试中，优化前后的写入速度差仅为0.49 Mb/s，但是在整体折线图的分布上，优化后写入性能有着明显提升。此外通过以上测试可以看出，读取速度明显优于写入速度，这主要是由于Android所使用NAND闪存介质本身读取性能远高于写入性能导致的。对以上测试数据进行统计计算后，本方案优化后文件系统的读写性能提升约11.8%。接下来编写程序测试优化前后EXT4对不同大小文件的读写时间，通过O_DIRECT标志绕过文件系统缓存，对各种大小的文件分别测试10次统计平均值，测试结果如图9所示。

图9 不同文件大小读写时间测试

如图9所示，纵坐标代表不同大小文件的读写速度，修改后EXT4对相同大小文件的读写花费的时间相比于原内核更短。在文件较小时，优化前后花费的时间差别较小；但是当文件较大时，优化后所花费的时间有着明显的减少。这是因为对于小文件来说，可能触发的垃圾回收过程较少甚至不需要进行垃圾回收，因此本方案优化效果不明显，但是在进行大文件的读写时，会触发更多的闪存垃圾回收，本方案能够减少闪存垃圾回收中对无用日志数据的拷贝消耗，因此提升效果较为明显。

5 结论

本文提出一种提高EXT4文件系统性能优化方案，首先记录数据同步事务处于Finished状态时日志数据的逻辑区块地址，结合上一事务记录下的逻辑区块地址，令本次日志数据所在闪存物理页面无效，最后在垃圾回收时清除闪存设备的无用日志数据，从而避免日志数据的冗余拷贝。

通过实验对比，本文方法能够减轻闪存设备因日志数据造成的“写放大”现象，同时能够在增强EXT4文件系统读写效率的同时，延长闪存设备的使用寿命。

在本文研究基础上，下一步研究工作主要有以下几个方面，考虑除日志数据以外导致Android存储性能下降的其他因素，例如针对SQLite与EXT4的日志记录不协调问题进行优化研究等，实现Android I/O栈从应用程序至底层硬件设备的一整套优化方案，进一步提高Android智能手机的存储性能。