文件系统fsck提速方案

admin

在分布式文件系统（例如HDFS）中，当出现异常掉电、加电恢复后，通常存储系统会检测内部数据的一致性，检测分为两个层次

首先是单机文件系统的数据一致性检查
其次是使用了erasure coding编码的存储系统进行数据一致性校验

必要时进行根据erasure coding进行数据恢复。
根据阿姆达尔定律，存储系统恢复的整体时间由串行部分最慢的节点决定。
在 ec 恢复的过程中，通常是多个节点，多个设备之间并行恢复，系统的瓶颈通常受限于第一阶段本地文件系统的 fsck 过程。
在类 HDFS 中，通常使用 SATA 硬盘存储数据，SATA 硬盘的磁盘容量随着新的SMR、HAMR技术的出现而越来越大，而传输的速率目前受限于 SATA3.0定义的最大速率（6Gb/s，实际使用中通常顺序读稳定在 100-150MB/s 之间），因此提升文件系统的fsck速度就显得愈发重要，本文中以 ext4 文件系统为例，列举除了文件系统 fsck 提速的若干方案。
方法1：优化文件系统及 fsck 本身
Ted 在 e2fsprogs版本1.41.9中已经完成了针对 ext4 的 fsck 优化工作，而公司目前线上的 fsck 版本为 1.41.12 ，已经加入了这个优化。
从优化fs check本身考虑，《ffsck: The Fast File System Checker》中提出了对于ext3磁盘数据格式进行修改，在每个block group内部加入专为元数据存储的空间，以优化fsck中磁盘对于元数据的随机寻址(e2fsck中 phase1/扫描文件间接索引占据了总时间的90%以上)，进而提高性能，由于需要修改磁盘上数据存储的格式，所以此方法不可行。
思路：
建议如果需要优化fscheck本身，下一步可以考虑和应用类型结合起来进行（例如找到应用关心的文件进行检查，不关心的直接跳过，对于hadoop hdfs之类的数据存储，目录和文件均有用，因此此方法不适合），并且在mkfs的时候，使用bigalloc和inline data的功能，大文件保证其连续性，减少元数据存储量，小文件可以直接合并入 inode，减少 seek 的程度，不过这种方案并未从根本上解决问题，随着文件系统碎片的增加，可能抵消掉带来的性能提升。

方法2: online fsck
ZFS，BTRFS 等由于采用了 COW 机制，对写入磁盘的数据不会再进行修改，保证存盘数据的稳定性，在恢复之后可以立即对外提供服务，将对断电时刻的数据检查作为一个优先级较低的操作（ZFS为scrub操作），可以和文件系统的正常操作并行执行，一旦有正常的读写等操作，将会停止 fsck 过程，减少对于应用性能的影响。
由于数据库等系统需要尽可能的在线提供服务，所以我们希望能够尽可能的缩短宕机后的启动时间。所以，如果可以实现 online fsck 的功能，则可以尽可能的缩短系统启动的时间，同时保证文件系统不被破坏。
目前已知的可以进行online fsck的文件系统是 zfs, ffs, btrfs。
Ted 给出的建议是可以考虑在分配磁盘块的时候在相应的 block group 上添加相应的标记，表明这个block group 正在进行磁盘块的分配，在出现宕机后，这个 block group 的数据只进行读操作，所有写操作都会被映射到其他的 block group中。这样可以尽可能的保证文件系统的一致性（来自ext4 workshop总结）。
鉴于kernel mainline已经明确表明不会接受ext4 snapshot的 patch，所以基于 fs 的 snapshot 进行 online fsck无法进行，可以尝试结合比较成熟的 lvm 快照为 fsck 提速。
Andreas的回复： *
When you write about online e2fsck, what do you mean exactly? It is already possible
with LVM to create a read-only snapshot of a device and run read-only e2fsck. This
works because the LVM snapshot is hooked to ext4 to freeze the filesystem and flush
the journal before the snapshot is done.
Ext4 snapshots vs lvm snapshots
*
如何在已有的分区上创建lvm卷组
思路：
遇到宕机/掉电导致的 fsck 时间过长时，将已有的分区转换为 lvm 分区，然后在lvm快照的基础上进行 online fsck，此时文件系统可以挂载供应用读取（读写未出错的文件）。 优势：从根本上免除了 fsck 带来带来的时延。
劣势/待解决问题

fsck 完成后如何清除 lvm 返回到raw partition的状态
是否可以控制不使用第二块盘进行重定向(提前保留部分空间)
了解到目前这种lvm online fsck启动后会对应用的性能产生较大的影响，因此建议使用文件系统内置的online fsck功能。

方法3：跳过fsck步骤
google 内部使用 ext4 时采用了no journal的挂载选项，说明在宕机、断电过程后并不进行 fsck，而是通过上层应用对于数据的冗余保证数据的一致性。
思路：
如果上层是 HDFS 之类的分布式文件系统，可以考虑这种思路，但需要注意到副本在同一个机房内，机房断电的情况。
针对以上的思路涉及如下实验验证：
测试：
测试环境：ST4000NM0053-1C1 2TB的硬盘+hadoop hdfs 写入 1.3TB 数据（共个 38949 文件，331 个目录）

测试1：内核版本 3.10.16 (支持bigalloc+inline_data)+打了 bigalloc 支持补丁的 e2fsprogs 测试(fsck工具不支持inline_data，会 crash)，mkfs 选项：mke2fs -m 0 -C 1MB -I 4096 -O bigalloc $device
测试2： 2.6.32内核+ e2fsprogs 工具(版本 1.41.12 )mkfs选项：mkfs.ext4 -F -m 0 -b 4096 -Tlargefile （实际环境中 mkfs 选项）,测试中fsck参数均为-f -y

结果：测试1 fsck 3次平均时间12s。测试2 fsck 3次平均时间40s。
从测试结果可见，如果不能使用方法3中上层屏蔽fsck或者方法2中使用lvm及COW文件系统的情况下，切换到使用了bigalloc和inline data的新版内核为比较稳妥的解决方案。

声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。