作者：張宇，北亞硬盤數據恢復中心，轉載請聯繫作者，如果實在不想聯繫作者，至少請保留版權，謝謝。
不管是哪種文件系統，其根本目的都是相同的：如何把文件存在系統給定的區域裏，如何有效地管理文件的讀與寫。爲實現這樣的目的，驅動層需要完善、周密地應付附加在文件系統上的各種操作。這些操作通常不會是一條指令完成的，如果一個過程需要多條指令完成，在執行這些操作時，全部指令未完成的情況下產生中斷，那這個文件系統便會出現一致性錯誤(或者叫連續性錯誤)。
爲了保證儘可以少的出現一致性錯誤，現在主流的文件系統都會設計成日誌型的。日誌型文件系統的主要特點就是把一個操作的所有指令執行過程都另外緩衝下來，如果全部執行完成再清除日誌標誌，如果操作沒有執行完成，可以在重新激活後通過日誌回溯或繼續完成。
EXT3的日誌功能通過在EXT2的設計基礎上增加一個特殊的文件(通常是８號節點文件)，在這個文件中記錄文件系統的操作過程。但EXT系統文件系統本身在節點、間接索引塊、目錄節點方面沒有冗餘保護，所以當文件系統除日誌外的其他結構並不一致，卻又要通過fsck來進行修復，這種一致性有可能將原本正確的結構也錯誤化。(就像原來是1+2=3，現在錯成了1+3=3，也許改完後變成了1+3=4，就完全沒辦法還原成最早的1+2=3)。
數據恢復領域經常會遇到這類情況：一次RAID出故障後，下次啓動系統提示做fsck，但做完後，也無法mount分區或者mount 分區後數據全是錯的。需要對這類情況進行數據修復的難度是很大的，從一個完整的結構(fsck後實際上從系統角度看已經是完整的了)再構建另一個完全不同的結構要比修正一個錯誤的結構更難以下手。其實這類情況，很多是因爲RAID5有早離線的盤加入了兩個邏輯磁盤組，導致所有的數據流是以新+舊的方式交錯組成的，自然會有太多錯誤。這時候如果做fsck後，有可能數據都無法恢復了。
所以，在EXT3（實際上其他文件系統也類似）無法mount，或者提示fsck時，如果有重要數據，應該慎重對待，千萬不可貿然執行"fsck -f -y "這樣的自動修復功能。如果可能，先對故障區域做dd全鏡像後再執行，或者以只讀方式執行，並仔細看修復過程，如果提示大量inode錯誤、需要重建樹、或大小不對等就不可再繼續下去了。