Ext3日记文件系统为什么文件系统还会损坏?
问题提出
0:<2>EXT3-fs error (device sda1): ext3_valid_block_bitmap: 0:Invalid block bitmap - block_group = 2, block = 65538 0:0:<2>EXT3-fs error (device sda1): ext3_new_block: 0:Allocating block in system zone - blocks from 65680, length 1 0:0:<2>EXT3-fs error (device sda1): ext3_new_block: 0:Allocating block in system zone - blocks from 65682, length 1 0:0:<2>EXT3-fs error (device sda1): ext3_new_block: 0:Allocating block in system zone - blocks from 65686, length 1 0:0:<2>EXT3-fs error (device sda1): ext3_new_block: 0:Allocating block in system zone - blocks from 65688, length 1 0:0:<2>EXT3-fs error (device sda1): ext3_valid_block_bitmap: 0:Invalid block bitmap - block_group = 4, block = 131074 0:0:<2>EXT3-fs error (device sda1): ext3_new_block: 0:Allocating block in system zone - blocks from 131216, length 1 0:
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
fsck.ext3: while determining whether /dev/sda1 is mounted
/dev/sda1: recovering journal
/dev/sda1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 171367, i_blocks is 1312, should be 1320. Fix? yes
Pass 2: Checking directory structure
Entry '..' in ??? (114307) has deleted/unused inode 114246. Clear? yes
Entry '..' in ??? (114308) has deleted/unused inode 114246. Clear? yes[ below is removed... ]
原因分析
![](https://images2015.cnblogs.com/blog/756873/201512/756873-20151209172648043-1254652079.png)
硬件设备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文件系统都缺少有效的检测、恢复手段。
制定对策
- 加强存储设备的选型和验证,加强丰富存储设备的准入测试。
- 完善存储设备配置,关闭对数据一致性影响大的存储设备特性。
- 增加UPS、大电容,减少掉电对数据一致性的影响。
- 更换一致性更好的文件系统。
-EOF-