Ext3日記文件系統為什么文件系統還會損壞？

問題提出

     在我們產品使用的多種文件系統中，ext3文件系統問題的一致性問題比較突出（這里的文件系統一致性問題特指文件系統元數據的一致性，下同）。比如下面2例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... ]

保證文件系統一致性的手段很多，各文件系統采用的方案也不盡相同，如修復工具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文件系統一致性差問題的對策概括來說，主要有如下幾條：

1. 加強存儲設備的選型和驗證，加強豐富存儲設備的准入測試。
2. 完善存儲設備配置，關閉對數據一致性影響大的存儲設備特性。
3. 增加UPS、大電容，減少掉電對數據一致性的影響。
4. 更換一致性更好的文件系統。

-EOF-