Ｌｉｎｕｘ日志文件系統故障處理策略的研究

摘要：研究了三種廣泛應用的Linux日志文件系統Ext3、ReiserFS和IBM JFS在磁盤寫失效情況下的故障處理機制，分析了它們在處理磁盤寫失效時存在的設計不足，并對文件系統磁盤故障處理的改進進行了總結和研究。

關鍵詞：日志文件系統;故障處理;Ext3;ReiserFS;IBM JFS

中圖分類號：TP316文獻標志碼：A

文章編號：1001-3695(2007)12-0060-03

磁盤發生故障是很難避免的事情，為了確保磁盤故障后文件系統的完整性和可靠性，文件系統需要通過合理的內部機制來處理這種故障。目前常用的文件系統普遍缺乏合理的磁盤故障處理機制，文件系統在磁盤發生故障時經常會有文件數據被破壞、數據丟失、文件或目錄丟失等情況發生。不合理的磁盤故障處理機制極大地影響了文件系統的完整性和可靠性。Ext3、ReiserFS和IBM JFS是三種常用的Linux日志文件系統，文獻[1，2]對三種日志文件系統的讀寫性能進行了研究，本文將著重研究文件系統在磁盤寫失效情況下的故障處理機制。首先介紹日志文件系統；然后討論它們在處理磁盤寫失效時存在的缺陷，分析比較每種文件系統的不足；最后總結研究了兩種文件系統故障處理策略的改進實現。

1日志文件系統

與早期的文件系統（如FFS和Ext2）不同，日志文件系統在磁盤上以日志的形式記錄一些額外的數據改變信息，在系統崩潰后利用日志快速恢復到以前的一致狀態，從而避免了掃描整個文件系統這種費時的完整性檢查。在日志文件系統中，每提交一個寫操作都會先寫日志。只有這些寫操作成功地提交到日志文件，數據才會寫進最終指定的磁盤區域。把日志中記錄的數據塊傳送到指定磁盤區域的過程稱為檢查點執行（checkpointing）。如果檢查點執行過程中發生故障，文件系統可以通過日志文件恢復數據到指定磁盤區域。日志文件系統通過周期性地更新日志超級塊來標記日志文件的大小和檢查點執行的中止。

1．1日志模式

文件系統提供了不同的日志模式，它們在磁盤更新操作時有些細微的不同。a）Data journaling提供最強的數據完整性。每個寫入磁盤的數據塊，不管是數據信息還是元數據信息，都先寫入日志。只有數據塊成功地提交到日志文件后，數據塊才會寫進指定的磁盤區域。b）Writeback journaling日志只記錄文件系統的元數據，它不關心數據寫磁盤區域和寫日志文件的順序。在確保元數據一致性時，writeback journaling并不保證數據的一致性。c）Ordered journaling在writeback journaling的基礎上添加了數據一致性。實現的方式是限制寫操作的順序，即文件數據在寫入指定磁盤區域之后再提交更新元數據。這種寫順序限制確保了文件元數據不會指向無效數據。

1．2Ext 3文件系統

Linux Ext3文件系統是建立在Ext2文件系統基礎上的日志文件系統。在Ext3文件系統中，數據和元數據的存放均采用標準的Ext2文件系統結構。Ext3日志以一個普通文件的形式存放在文件系統中，它也可以存放于一個獨立的存儲設備或不同的分區。日志文件包含不同的塊來跟蹤提交給日志的事務和數據塊：日志描述塊（journal descriptor block）記錄了存儲到日志中的指定區域數據的塊數；日志提交塊（journal commit block）標記事務的終止；日志超級塊（journal superblock）存儲日志信息，如日志頭、日志尾及下一個事務的ID號等。

圖1描述了Ext3文件系統的磁盤布局結構。該圖給出的是一個塊組的結構示意圖，整個文件系統是由許多這種相同結構的組組成的。Ext3支持上述三種日志模式。

1．3ReiserFS文件系統

ReiserFS文件系統是一種基于平衡樹結構的日志文件系統。每個文件系統采用一個特殊的、優化的平衡樹來組織所有的文件系統數據，根據需要動態地分配索引節點，能靈活適應各種存儲需要。ReiserFS日志與Ext3日志類似，采用循環寫的方式記錄日志，并以塊為最小的寫單位。ReiserFS與Ext3的不同之處主要有以下三個方面：a)磁盤數據布局結構不同。Ext3采用Ext2的結構；ReiserFS采用B＋樹結構，數據存儲在樹的葉子節點，元數據存儲在樹的中間節點。b)日志的格局有所不同。Ext3的日志是一個文件，可以存儲在分區的任何地方甚至是不同的設備上，存儲空間也不要求是連續的；ReiserFS日志不是一個文件，而是位于文件系統開始的一序列連續的塊，并限制了最大為32 MB。c)日志內容有所不同。ReiserFS支持上述三種日志模式。

1．4IBM JFS文件系統

IBM JFS是一種提供日志的字節級文件系統，是為面向事務的高性能系統開發的。IBM JFS只工作于ordered journaling模式，與Ext3和ReiserFS不同，它不支持data journaling和writeback journaling模式。IBM JFS寫進日志的信息也與Ext3和ReiserFS不同，Ext3和ReiserFS將整塊數據寫進日志，而IBM JFS寫進日志的是修改的塊數據，指定數據塊的寫與其他文件系統一樣。由于IBM JFS日志記錄修改的數據塊，日志塊就不能被分類為日志數據塊或者日志提交塊等。一個日志就包含了日志數據記錄和提交記錄。

2文件系統故障處理分析

文件系統一般只將磁盤分為正常工作和停止工作兩種狀態。隨著磁盤復雜性的提高，磁盤出現故障的形式也變得多種多樣，比如可能出現潛在的扇區故障，一個塊或幾個塊無法訪問，或者出現無聲的數據毀壞（silent data corruption）等，故障可能是暫時性的也可能是永久性的^[3]。文獻[4，5]采用故障插入技術（faultinjection methodology）對上述三種日志文件系統進行了分析，發現文件系統在磁盤故障處理機制方面存在的設計不足和缺陷。下面總結了幾種導致文件系統故障的磁盤寫失效處理方式，分析比較了三種文件系統在磁盤寫失效情況下的故障處理機制的設計不足。

2．1幾種磁盤故障處理方式

1)提交失效事務文件系統的每一個I/O操作叫做一個事務。當一個事務在寫磁盤失效后，文件系統繼續將該事務寫進日志并提交，從而導致文件系統處于不一致狀態。例如，在ordered journaling日志模式下，當一組有序數據寫失效，文件系統應該中止該事務，取消該事務的日志記錄。如果日志記錄并提交了該事務，元數據塊就指向了錯誤或者舊的磁盤數據內容。

3）無重寫失效的檢查點檢查點執行的過程就是將日志記錄的數據寫到指定磁盤區域。當檢查點執行時出現寫失效，文件系統必須試圖重寫或者在日志中標記下次重新執行該檢查點。忽略這種寫失效的情況會導致文件出現數據被破壞、數據丟失、文件和目錄丟失等現象。

4）日志文件寫失效處理不當日志文件系統通過標記日志文件為臟或干凈來維護兩種不同的狀態。文件系統在裝載時，如果日志標記為臟，日志記錄的事務將被重新執行。一般情況下，在開始一個事務前或檢查點執行完一個事務后日志標記會改變。如果日志標記的更新失效，可能會發生以下兩種情況之一：a)文件系統重新執行了事務，但該事務是不需要重新執行的；b)文件系統未重新執行事務，而該事務是需要重新執行的。第一種情況不會影響系統的完整性，而第二種情況將導致文件破壞或數據丟失。另外當寫日志數據失效時，事務應該中止并不再執行。如果該事務繼續執行，日志中的無效數據就會被讀寫到指定的磁盤區域，導致文件系統錯誤。

5)文件系統崩潰當磁盤寫失效時，通過系統調用（如Panic）來迫使整個文件系統停止工作；在下一次文件系統使用時必須重新啟動整個系統。文件系統崩潰使得失效的事務不會提交到磁盤，系統重啟并裝載文件系統后，文件系統執行恢復操作處于一致狀態。系統崩潰不僅會中止文件系統進程，同時也影響了系統中的所有其他進程。

2．2三種文件系統故障處理的比較分析

根據以上分析可以發現，Ext3的設計只考慮了系統的整體故障情況，而對于單個數據塊寫失效并沒有進行有效處理。Ext3的主要缺陷是它沒有中止失效事務，提交失效事務導致嚴重的文件系統錯誤，輕則數據被破壞，重則文件系統無法卸載。ReiserFS避免了許多Ext3出現的問題，但是要以整個系統重啟為代價。在處理寫失效時，ReiserFS將一個故障阻塞系統變為一個故障終止系統。然而如果出現永久性的磁盤故障，ReiserFS的這種設計將導致系統反復重啟而不可用。IBM JFS的設計缺陷是Ext3和ReiserFS所討論過的，如提交失效的事務、不重復執行失效的檢查點、IBM JFS在日志超級塊寫失效時與ReiserFS一樣使系統重啟等。

下面從文件系統可靠性、系統健壯性和數據完整性三個方面對以上分析的文件系統進行比較：

a ）文件可靠性。在磁盤寫失效時，Ext3主要存在的問題是文件數據被破壞、文件數據丟失、文件和目錄丟失，有時候也會出現文件系統無法卸載的情況；ReiserFS主要表現為系統崩潰重啟；IBM JFS的主要問題是文件數據被破壞和文件系統無法卸載，有時候也會出現文件數據丟失、文件和目錄丟失、系統崩潰的情況。從文件可靠性的角度考慮，ReiserFS系統的文件可靠性較Ext3和IBM JFS更高。

b）系統健壯性。文件系統無法卸載，甚至整個系統崩潰，都極大影響了系統的健壯性。在磁盤寫失效時，ReiserFS大多數情況下是通過Panic系統調用來迫使整個文件系統失效。與ReiserFS類似，IBM JFS在某些寫失效的情況下使系統崩潰重啟。例如在裝載操作時，日志超級塊寫失效將導致系統崩潰。相對而言，Ext3的系統健壯性最好。

c）數據完整性。磁盤故障處理機制會影響文件系統的數據完整性，以上討論的提交失效事務和檢查點寫失效無重寫會影響到文件系統的完整性。Ext3和IBM JFS均存在這兩方面的設計缺陷。因此在故障處理機制方面，ReiserFS提供較強的數據完整性。

3文件系統故障處理策略的改進研究

目前研究提出了以下兩種改進的故障處理文件系統，IRON文件系統Ixt3和奇偶校驗文件系統PFS。它們都是在Ext3文件系統的基礎上改進實現的。

3．1IRON文件系統Ixt3^[6]

IRON(internal robustNess)文件系統是一種具有故障檢測和恢復功能的文件系統。Linux Ixt3文件系統是在Ext3文件系統基礎上采用了校驗和、同步復制、奇偶校驗技術的IRON文件系統。與Ext3文件系統相比，該文件系統在時間和空間的開銷上有所增加，但文件系統的健壯性有了顯著的提高。

1）Ixt3文件系統的設計

a)校驗和。Ixt3采用SHA1計算文件數據塊的校驗和，校驗和先寫進日志，然后通過checkpoint操作寫進指定磁盤區域。校驗和占用很小的空間，在讀文件操作時可以存放于cache中使用。

b）同步復制。Ixt3采用了同步的元數據復制，所有的元數據塊被同步寫進一個獨立的備份日志，該日志通過checkpoint寫進遠離原始元數據的指定磁盤區域。元數據的同步復制采用了事務機制來確保備份元數據的一致性。

c）奇偶校驗。Ixt3修改了Ext3文件系統的節點結構，為每個文件分配一個奇偶校驗塊。當文件被修改時，根據文件修改的數據對奇偶校驗塊進行更新。系統采用了預分配奇偶校驗塊的方法來改進創建文件的性能。

2）Ixt3文件系統的性能

a）時間開銷。測試發現，Ixt3在SSHbuild和網頁服務器基準測試中的時間開銷與Ext3系統的開銷相當，沒有大的變化；在postmark基準測試中，Ixt3比Ext3的時間開銷增加了37％；TPCB基準測試中Ixt3比Ext3的時間開銷增加了42％。后兩種環境下元數據操作較多。

b）空間開銷。試驗證明，校驗和以及元數據復制的空間開銷較小，占總空間的3％~10％；奇偶校驗的空間開銷較大，占總空間的3％~17％。

3．2奇偶校驗文件系統^[7]

奇偶校驗文件系統（parity file system，PFS）的設計思想是在Ext3文件系統的設計基礎上加上奇偶校驗塊，對每個文件數據塊進行奇偶校驗。如果該文件出現單個數據塊失效的情況，就可以通過奇偶校驗塊對失效的數據塊進行恢復。

1）PFS的設計

PFS對Ext3代碼進行了少量的修改以包含奇偶校驗。文件在寫第一個數據塊時，為該文件分配一個奇偶校驗塊并置為零，該數據塊寫完時，奇偶校驗塊的內容與該數據塊內容相同；接下來在寫其他數據塊時，校驗塊的內容為當前內容與新數據塊內容的異或。如果某一數據塊更新時，新校驗塊內容由以下公式得到：

新的校驗塊＝新數據塊XOR舊數據塊XOR舊校驗塊

該設計修改了Ext3系統的兩個文件，即ext3_fs.h和inode.c。其中ext3_fs.h的修改如下：

/* Constants relative to the data blocks */

#define EXT3_NDIR_BLOCKS 11/*11 instead of 12 direct pointers*/

#define EXT3_IND_BLOCK EXT3_NDIR_BLOCKS

#define EXT3_DIND_BLOCK (EXT3_IND_BLOCK+1)

#define EXT3_TIND_BLOCK (EXT3_DIND_BLOCK+1)

#define EXT3_N_BLOCKS (EXT3_TIND_BLOCK+2)/*in order to maintain 15 pointers in inode， instead of EXT3_TIND_BLOCK+1*/

inode.c主要修改了ext3_prepare_write()、ext3_journalled_commit_write()、ext3_ordered_commit_write()、ext3_block_to_path()等函數。

2）PFS的性能

測試結果顯示，PFS在創建文件時的工作負荷與Ext3文件系統基本沒有區別。追寫文件數據時，PFS需要讀取當前奇偶校驗塊并計算更新奇偶校驗塊，因此相對Ext3系統降低了30％~50％的帶寬。在文件數據局部修改時，兩者的性能基本沒有區別。

4結束語

本文分析的三種Linux日志文件系統在磁盤故障處理機制方面均存在不足之處。為了提高系統的可靠性、健壯性、完整性，文件系統的設計在磁盤故障處理策略方面需進一步完善。目前研究提出的兩種改進故障處理策略的設計在一定程度上提高了系統的可靠性和健壯性，但系統的時間和空間開銷也相應增加，同時具有一定的局限性，如奇偶校驗只能恢復單個數據塊出現錯誤的情況，而磁盤出現連續的多個數據塊故障時數據無法恢復。設計出能處理磁盤故障的更可靠、更健壯的文件系統是對文件系統故障處理策略的進一步研究。

參考文獻：

[1]PRABHAKARAN V， ARPACIDUSSEAU A C， ARPACIDUSSEAR R H. Analysis and evolution of journaling file systems[C]//Proc of USENIX Annual Technical Conference (USENIX ’05). Anaheim:[s.n.]，2005:105-120.

[2]張文江，吳慶波．Linux日志文件系統研究[J].計算機工程與應用，2006，42（9）:50-52.

[3]Data Clinic. The hard disk failure[EB/OL].[2006-06-20].http://www.dataclinic.co.uk/harddiskfailures.htm.

[4]PRABHAKARN V， ARPACIDUSSEAU A C， ARPACIDUSSEAU R H. Modelbased failure analysis of journaling file systems[C]//Proc of International Conference on Dependable Systems and Networks. 2005:802-811.

[5]YANG J， TWOHEY P， ENGLER D， et al. Using model checking to find serious file system errors[C]//Proc of the 6th Symposium on Operating Systems Design and Implementation. New York:ACM Press，2004:273-288.

[6]PRABHAKARAN V， BAIRAVASUNDARAM L N， AGRAWAL N. IRON file systems[C]//Proc of SOSP’05. Brighton:[s.n.]，2005:206-220.

[7]APTE H， RUNGTA M. Parity file system[R]. Wisconsin， Madison: Computer Sciences Department， 2005:1-10.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”