Ext3日记文件系统为什么文件系统还会损坏？

问题提出

在我们产品使用的多种文件系统中，ext3文件系统问题的一致性问题比较突出（这里的文件系统一致性问题特指文件系统元数据的一致性，下同）。比如下面2例ext3文件系统损坏案例：





保证文件系统一致性的手段很多，各文件系统采用的方案也不尽相同，如修复工具fsck（ext2），journal-based（ext3），log-structure（btrfs、ubifs）。虽然手段各异，但一致性的目标应该都是能满足的，但为什么我们产品使用的ext3文件系统的CF卡的存储设备频频出现文件系统损坏问题呢？

原因分析

上图是我对ext3一致性问题来源和解决措施的思考脑图。脑图的叶节点（有钥匙标识）是可能的解决方法。
脑图的分析过程比较详细，就不在赘述，下面按硬件问题和软件bug两方面简单总结一下。

硬件设备bug

硬件故障分为2部分：存储设备和控制器设备。存储设备作为黑盒设备，如果偶发故障固件SMART不上报、不记录，作为用户就无从得知。存储设备一般都有ECC、坏块管理等功能，但生产商水平参差不齐，这块做的不好，势必会影响文件系统的一致性。

相对来说，控制器的硬件接口标准化，驱动代码开源，出现问题较好定位，而且AHCI/EHCI等标准总线协议都支持CRC校验。

另外，电源设备故障造成的掉电也是造成数据一致性的重要来源，设备有UPS支持，或者设备上有大电容作为掉电应急支持，或者采购支持掉电保护的存储设备，这能从根源上大大减少文件系统破坏的可能性。

笔者在存储设备生产商工作过一段时间，深知存储设备固件里面的水很深。存储设备生产商为了在各种benchmark工具中提高竞争力，往往会针对benchmark工具的测试行为进行优化。而且为了提高存储读写性能，往往会对标准命令做手脚，比如下发了write cache关闭命令却实际上没有关闭、不支持cache同步命令（Sync Cache、Flush）命令（如创见 SLCFxxxM2TU型号的CF卡），或者下发了但并没有处理、不支持FUA等等，作为用户却无法感知。

为了提高写性能，标准命令提供了NCQ、TCQ命令，这些命令有多队列、写排序、异步返回等特性，进一步加重了数据写入存储介质的时机不可控。如果更看重文件系统的一致性，最好和设备厂商咨询，是否禁用这些特性。有些非标准存储设备，会强制对写请求进行排序，这种情况只能通过下发cache同步命令来保证数据写入存储介质中。

软件bug

拿ext3和ubifs 2种不同类型的文件系统横向对比来看，不管从代码量（23858 vs. 54844)， 还是从开发历史（2001年 vs. 2008年），ext3文件系统应该比ubifs文件系统更加稳定，所以说文件系统bug基本上可以确认不是要因。

alex@alex-desktop:~/sc/bsp_dev/kernel/linux/linux-2.6.32-cgel$ find drivers/mtd/ubi/ fs/ubifs/ -name "*.[c|h]" | xargs cat | wc -l
54844
alex@alex-desktop:~/sc/bsp_dev/kernel/linux/linux-2.6.32-cgel$ find fs/ext3 fs/jbd -name "*.[c|h]" | xargs cat | wc -l
23858

从本文开头的2例故障日志可以看出，文件系统元数据损坏时，并没有看到日志错误。ext3文件系统不管采用哪种日志模式，文件系统元数据都是通过日志来保护的，所以可见，把日志模式改为journal还是writeback，并不能避免上面2例故障的发生。

所以说，ext3文件系统在文件系统一致性上存在较多不足。首先在文件系统模型上，journal-based文件系统无法从根本上提供文件系统更新的原子操作，而基于CoW技术（有的文件系统上叫做异地更新）的log-structure文件系统，从根本上解决了文件系统更新的原子操作。另外，ext3文件系统也缺少保证数据一致性的特性（很多特性ext4也没有），比如日志备份、日志支持校验、元数据块支持校验等等。所以不管应用程序bug还是文件系统bug导致的文件系统破坏，ext3文件系统都缺少有效的检测、恢复手段。

制定对策

根据上面的分析，解决我们产品中ext3文件系统一致性差问题的对策概括来说，主要有如下几条：

加强存储设备的选型和验证，加强丰富存储设备的准入测试。

完善存储设备配置，关闭对数据一致性影响大的存储设备特性。

增加UPS、大电容，减少掉电对数据一致性的影响。

更换一致性更好的文件系统。

-EOF-