AIX中的fsck詳解

在aix系統中fsck指令的用途 

當執行fsck 指令時，fsck 指令如果發現存在孤立的檔案或目錄，這些孤立的檔案或目錄對于系統管理者或使用者來說将無法通路。因為它與它的上級目錄失去了關聯，如果使用者允許fsck 重新把它們找回來的話，fsck 指令就會把這些孤立的檔案或目錄放在檔案系統的/lost+found 目錄下，并用各自的i-node 号來命名，以便使用者查找自己需要的檔案。lost+found 目錄通過它的英文含義我們都可以知道，它是一個失物認領處。 是以當某個使用者發現自己丢失了某個檔案，可以在執行fsck 之後到/lost+found 目錄下去查找，這時通過檔案名已無法辨認出檔案的作用，隻能用file 之類的指令來确定檔案的類型。如果是資料檔案，可以用more 或vi 指令來檢視，如果是二進制檔案，可以用dbx 指令來調試或者試着執行它（注意它可能是一個具有破壞性的程式），知道檔案或目錄的作用之後，可以對其進行改名。

如果使用者不允許fsck 把這些孤立的檔案或目錄找回來，那麼fsck 指令就會破壞這些檔案或目錄，徹底丢失這些檔案或目錄，使用者或系統管理者永遠也無法找回它們。 

文法

fsck [ -n ] [ -p ] [ -y ] [ -dblocknumber ] [ -f ] [ -ii-nodenumber ] [ -o options ] [ -tfile ] [ -v vfsname ] [ filesystem1 - filesystem2 ... ]

描述

注意: 在出現系統故障之後，總是運作 fsck 指令。矯正的動作也許會導緻某些資料的丢失。對于每一個一緻性的矯正，預設的操作就是等待操作員輸入 yes 或者 no。如果對于已經受到影響的檔案系統您沒有寫的許可，那麼無論您的實際響應是什麼，fsck 指令預設的動作都是 no。

注:

    對于一個已經安裝好了的檔案系統，fsck 指令不會做出矯正。

    fsck 指令出于某些原因可以在一個已經安裝好了的檔案系統中運作，但不是進行修複。但是當檔案系統安裝完畢之後，也許會傳回不準确的錯誤消息。

fsck 指令檢查并以互動方式修複不連貫的檔案系統。在安裝檔案系統之前，應該運作這個指令。您必須能夠讀裝置檔案，在這個裝置上駐留着檔案系統（例如/dev/hd0 裝置）。通常，檔案系統是連貫的，fsck 指令僅僅是報告檔案系統中檔案的數量、被使用的塊和空閑的塊。如果檔案系統是不連貫的，fsck 指令顯示關于那些找到的不連貫性的資訊并且提示您修複它們的許可。

fsck 指令在修複中是有保留的并且會盡力避免那些可能導緻有效資料丢失的動作。在特定的情況下，fsck 指令會建議破壞已經損壞的檔案。如果您不允許 fsck 指令進行必要的修複，那麼或許會産生一個不連貫的檔案系統。安裝一個不連貫的檔案系統也許會導緻系統的崩潰。

如果 jfs2 檔案系統有快照，fsck 指令将試圖保留這些快照。如果此操作失敗，則無法保證快照包含來自捕捉到的檔案系統的全部先前就存在的映像。fsck 指令将删除這些快照和快照邏輯卷。

如果您不用 filesystem 參數指定檔案系統，fsck 指令将會檢查在/etc/filesystems中列出的檔案check屬性将全部設為 true的所有檔案系統。您可以通過在每一節中加入一行啟用這種檢查，如下所示：

check=true

fsck 指令可以在多檔案系統中進行同步的檢查動作。這個過程可以減少檢查大量檔案系統所需的時間。當檔案系統被指定為參數的一部分的時候，采用負号“-”來分隔這些檔案系統。

您也可以通過在 /etc/filesystems 檔案中将檔案系統分組來進行多檔案系統的同步檢查工作。為了做這項工作，在/etc/filesystems 檔案中修改 check屬性，如下所示：

check=number

number參數告訴 fsck 指令哪一組包含特定的檔案系統。使用公共記錄裝置的檔案系統應該被放置在同一個組中。每一個組在分隔的平行程序中被檢查。檔案系統被檢查的時候，一次檢查一個，以便它們能夠在/etc/filesystems檔案中被列出。所有的 check=true 的檔案系統被分到 1 組。fsck 指令在檢查其它檔案系統之前會試着檢查根檔案系統而不管在指令行中或者 /etc/filesystems 檔案中指定的順序。

fsck 指令檢查下列的不連貫性：

    配置設定給多個檔案的塊或者段。

    包含交疊塊或者段數目的索引節點。

    包含超出範圍的塊或者段數目的索引節點。

    在對檔案的目錄引用數量和檔案連結計數之間的差異。

    非法配置設定的塊或者段。

    包含在磁盤映射中标記為空閑的塊或者段數量的索引節點。

    包含被破壞的塊或者段數目的索引節點。

    在索引節點中不是最後磁盤位址的段。檢查不會被用于壓縮檔案系統。

    包含一個段的超過 32kb 段的檔案。檢查不會被用于壓縮檔案系統。

尺寸檢查：

    塊的不正确數量。

    目錄的大小不是 512 位元組的整數倍。

    這些檢查不被用于壓縮的檔案系統。

    目錄檢查：

    目錄條目包含一個在索引節點映射中被标記為空閑的索引節點号。

    超出範圍的索引節點号。

    點（.）連結丢失或未指向其本身。

    點點（..）連結丢失或未指向父目錄。

    沒有引用的檔案或者不可到達的目錄。

    不連貫的磁盤映射。

    不連貫的索引節點映射。

如果您允許，那些孤立的檔案和目錄（那些無法到達的）可以通過将它們加到在檔案系統根目錄下的 lost+found 子目錄下面使它們重新連接配接起來。指定的名稱是索引節點号。如果您不允許 fsck 指令重新配屬一個孤立的檔案，它會請求破壞這個檔案的許可。

除了它的消息之外，fsck 指令會通過它的出口值來記錄檢查和修複的結果。這個出口值可能是下列情況的任意和:

0     所有被檢查的檔案系統現在都好了。

2     fsck 指令在結束檢查或修複之前被中斷了。

4     fsck 指令改變了檔案系統；使用者必須立即重新啟動系統。

8     檔案系統包含沒有修複的損壞部分。

當系統從磁盤進行引導，引導過程會很明确的運作 fsck 指令，以 /、/usr、/var、/tmp 檔案系統中的 -f 和 -p 标志指定。如果沒有成功的在這些檔案系統之一執行 fsck 指令，系統不會引導。在這樣的系統引導之前，從可删除的媒體引導并進行維護工作将會被需要。

如果 fsck 指令成功的在/、/usr、/var 和 /tmp中運作, 正常的系統初始化将會繼續進行。在正常的系統初始化過程中，fsck 指令同 -f 和 -p 标志一同指定，從/ etc/rc 檔案中運作。這個指令序列檢查所有的檔案系統，在其中check屬性設成了 true（ check=true）。如果 fsck 指令從 /etc/rc 檔案中執行，指令不能保證檔案系統的連貫性，系統初始化繼續進行。任何不連貫檔案系統的安裝也許會失敗。安裝失敗也許會導緻系統不完全的初始化，即部分檔案系統不能正确初始化(筆者淺見)。

在預設情況下/、/usr、/var 和 /tmp 檔案系統在/etc/filesystem 節的 check屬性被設成了 false（ check=false）。屬性被設成了 false 是由于下列原因：

    引導過程在/、/usr 、/var、和 /tmp 檔案系統中明确的運作了fsck 指令。

    當 /etc/rc 檔案被執行的時候，/ /usr 、 /var 和 /tmp檔案系統就被安裝了。fsck 指令不會修改一個已經安裝了的檔案系統。此外，在一個已經安裝好了的檔案系統上運作的 fsck 指令産生不可靠的結果。

您可以使用在基于 web 的系統管理器 (wsm) 中的檔案系統應用程式來改變檔案系統的特征。您也可以系統管理界面程式（smit）smit fsck 快速路徑來運作這個指令。

标志

-d blocknumber     搜尋指定磁盤塊的參考。無論 fsck 指令遇到包含特定塊的檔案，它将會顯示索引節點号和所有指向它的路徑名稱。對于 jfs2 檔案系統，引用指定子產品的索引節點号将會被顯示，但是不是它們的路徑名稱。

-f     進行快速檢查。在正常情況下，通過非正确方式關閉系統來停機僅有的檔案系統很可能被影響，這個檔案系統就是當系統停止時在安裝的那些。 -f 标志會提示 fsck 指令不要檢查沒有成功安裝的檔案系統。fsck 指令通過檢查檔案系統超級塊中的 s_fmod 标志來決定這件事。

當檔案系統沒有成功安裝的時候，無論何時檔案系統被安裝和被清除，這個标志都将被設定。如果檔案系統被成功的解除安裝，這不大可能會存在什麼問題。因為多數檔案系統沒有成功安裝，不檢查這些檔案系統能減少檢查時間。

-i i-nodenumber     搜尋指定索引節點的參考。無論何時 fsck 指令遇到一個指向指定索引節點的目錄，它都會顯示這個參考的完整路徑名稱。

-n     對 fsck 指令所提出的所有問題給出一個no的回應；不打開指定的檔案系統來寫。

-o 選項     向 fsck 指令傳遞逗号分隔的選項。這些選項被認為是檔案系統的實作細節，除了下面目前為了所有檔案系統而目前被支援的選項：

mountable

    如果有問題的檔案系統可安裝（清除），促使 fsck 指令成功的退出，傳回一個“0”值。如果檔案系統不可安裝，fsck 指令退出并傳回一個值“8”。 

mytype

    如果存在問題的檔案系統與在 /etc/filesystems 檔案中或者在指令行中通過 -v 标志指定的具有相同的類型，那麼促使 fsck 指令退出并給出一個成功的“0”值。否則，傳回一個值“8”。例如，如果/（引導檔案系統）是一個分類檔案系統，那麼 fsck 指令 -o mytype -v jfs / 會退出給出一個“0”值。 

-p     不顯示次要問題的消息但是自動修複問題。這個标志并不是象-y 标志那樣授予大規模許可，當系統正常啟動的時候對自動進行檢查工作有用。無論系統在何時自動運作，您應該将這個标志作為系統啟動過程的一部分來使用。也允許并行分組檢查。如果主要的超級塊損壞了，次要的超級塊就被驗證，并且複制到主要的進階塊中。

-t檔案     如果 fsck 指令得不到足夠的記憶體來儲存它的表的話，在檔案系統中作為一個臨時檔案而不是被檢查的檔案來指定file參數。如果沒有指定 -t 标志，那麼 fsck 指令需要一個臨時檔案，它會提示您給這個臨時檔案起名字。但是，如果指定了 -p 标志，fsck 指令是不成功的。如果臨時檔案不是一個特定的檔案，當 fsck 指令結束的時候，它就會被删除。

-v vfsname     使用為檔案系統由vfsname變量指定的虛拟檔案系統的描述，而不是用 /etc/filesystems 檔案決定描述。如果-v vfsname 标志沒有在指令行中指定，就會檢查 /etc/filesystems 檔案并且 vfs= 比對節的特性被認為是正确的檔案系統類型。

-y     對所有 fsck指令提出的所有問題假定一個“yes”的響應。這個标志使 fsck 指令采取它認為必要的行動。僅在損壞嚴重的檔案系統中使用這個标志。

示例

    為了檢查所有的預設檔案系統，請輸入：

    fsck 

    這個指令檢查在 /etc/filesystems 檔案中所有标記 check=true 的檔案系統。fsck 指令這種形式在對檔案系統做出任何更改之前會向您請求許可。

    為了利用預設的檔案系統自動修複較次要的問題，請輸入：

    fsck -p 

    為了檢查一個特定的檔案系統，請輸入：

    fsck /dev/hd1 

    這個指令檢查位于 /dev/hd1 裝置上的未安裝的檔案系統。

檔案

/usr/sbin/fsck     包含 fsck 指令。

/etc/filesystems     列出已知的檔案系統并且定義它們的特征。

/var/spool/mail/*     包含虛拟檔案系統類型的描述。

/usr/bin/from     包含當系統啟動的時候運作的指令（包括 fsck 指令）。

fsck的資料災難解決方案

[症狀]

1、無法mount分區;

2、大量檔案、目錄丢失，根目錄下生成/lost+found檔案夾，裡面有大量#xxxxxx類的檔案和目錄;

3、fsck很快報錯完成;

4、fsck執行時，有大量提示，如修改節點、清0節點等操作

[應急方案]

1、如遇提示fsck時，請小心。如果可能，請盡快斷開系統，umount所有分區。

2、必需執行fsck時，先做準備工作，方法一：可事先用dd指令将所涉及到的分區輸出到另外的存儲體上（最好不要在出錯的存儲體本身上做dd） 指令大緻結構可如： dd if=/dev/sda0 of=/dev/sdb0 .....

3、必需執行fsck時，先做準備工作，方法二：将整個aix存儲體挂載到虛拟機環境，将linux存儲體設為nonpersisten模式，再執行，執行過後，如果資料完好，應盡快通過ftp等方式拷貝出來。

4、必需執行fsck時，先做準備工作，方法三：将整個aix存儲體挂載到其他系統上（如windows），做好鏡像後再做fsck。

5、如上面幾種方式均因條件等原因無法實施，必須執行時，可小心觀察fsck的執行提示（關掉-a）如果發現有提示節點錯誤需更正或清0、節點描述檔案大小不正确等資訊，應停止執行fsck。

6、因恢複需要參考很多資訊，因盡可能保持系統不工作狀态，至少不得再次mount分區（即便不做任何讀寫操作，也會因系統的工作原理不斷降低資料恢複的可能性，增加資料恢複的難度）

7、尋求專業資料恢複公司幫助

           http://www.kuqin.com/aixcmds/aixcmds2/fsck.htm

           http://www.cnw.com.cn/weekly/htm2006/20061219_49157.shtml

本文原創，轉載請注明出處、作者

如有錯誤，歡迎指正

郵箱:[email protected]

作者：czmmiao 原文位址：http://czmmiao.iteye.com/blog/1148106