【簡介】 fsck命令被用於檢查並且試圖修複文件系統中的錯誤。當文件系統發生錯誤四化，可用fsck指令嘗試加以修複。【選項】必要參數 -a 非互交模式，自動修複 -c 檢查是否存在有損壞的區塊。 -C<反敘述器> fsck.ext3命令會把全部的執行過程，都交由其逆向敘述，便於監控程式 -d 詳細顯 ...
【簡介】
fsck命令被用於檢查並且試圖修複文件系統中的錯誤。當文件系統發生錯誤四化，可用fsck指令嘗試加以修複。
【選項】
必要參數
-a 非互交模式，自動修複
-c 檢查是否存在有損壞的區塊。
-C<反敘述器> fsck.ext3命令會把全部的執行過程，都交由其逆向敘述，便於監控程式
-d 詳細顯示命令執行過程
-f 強制進行檢查
-F 檢查文件系統之前，先清理該保存設備塊區內的數據
-l<損壞區塊文件> 把文件中所列出的損壞區塊，加入標記
-L<損壞區塊文件> 清除所有損壞標誌，重新標記
-n 非交互模式,把欲檢查的文件系統設成只讀
-P<數字> 設置fsck.ext2命令所能處理的inode大小為多少
-r 交互模式
-R 忽略目錄
-s 順序檢查
-S 效果和指定“-s”參數類似
-t 顯示fsck.ext2命令的時序信息。
-v 顯示詳細的處理過程
-y 關閉互動模式
選擇參數
-b<分區第一個磁區地址> 指定分區的第一個磁區的起始地址/Super Block
-B<區塊大小> 設置該分區每個區塊的大小
-I設置欲檢查的文件系統，其inode緩衝區的區塊數目
-V顯示版本信息
【適用】
1) 文件系統：ext2 ext3 reiserfs xfs等
2) 範圍：提示文件系統需要FSCK時，未執行或FSCK執行完成
【癥狀】
1) 無法MOUNT分區;
2) 大量文件、目錄丟失，根目錄下生成/LOST+FOUND文件夾，裡面有大量#XXXXXX類的文件和目錄;
3) fsck很快報錯完成;
4) fsck執行時，有大量提示，如修改節點、清0節點等操作
【應急】
1，如遇提示fsck時，要小心，如果可能，請儘快斷開系統，umount所有分區
2，必須執行fsck時，先做準備工作，方法一：可實現用dd命令所有涉及到的分區輸出到另外的存儲體上，命令大致所示：dd if=/dev/sda1 of=/dev/sdb1
3，如上面幾種方式均因條件等原因無法執行，但又必須執行時，可小心觀察fsck的執行提示(關掉 -a) 如果發現有提示節點錯誤需更正或清0，節點描述文件大小不正確等信息，應停止執行fsck
【備註】
1，如果可能，先對故障區做dd全鏡像備份後在執行，或者以只讀方式自行，並仔細看修複過程，如果提示大量inode錯誤，需要重建樹、或大小不對等就不可再繼續下去了
2，文件系統常見錯誤，並且問題通暢原因是電源失敗，硬體失敗，或者操作失誤，例如沒有正常關閉系統
3，fsck只能運行於為mount的文件系統，不要用於已mount的文件系統
4，修複完成後，會出現提示“FILE SYSTEM WAS MODIFIED”。這時重啟系統
【參考範例】
手動fsck修複
fsck不僅可以對文件系統進行掃描，還能修正文件系統的一些問題。值得註意的是fsck 掃描文件系統時一定要在單用戶模式、修複模式或把設備umount後進行。
警告：如果掃描運行中的系統，會造成系統文件損壞。
文件系統掃描工具有 fsck，fsck.ext2，fsck.jfs，fsck.msdos，fsck.vfat，fsck.ext3，fsck.reiserfs（reiserfsck）。其中fsck 預設支持文件系統ext2，如果想支持ext3文件系統的掃描，應該加-j 參數。最好是根據不同的文件系統來調用不同的掃描工具，比如ext3的文件系統使用fsck.ext3，ext2文件系統使用fsck.etx2等。
/dev/sdb1是ext3的文件系統，只介紹fsck.ext3
範例1： 檢測磁碟
[root@linux test]# fsck.ext3 /dev/fd0
範例2： 檢測磁碟並顯示時序信息
[root@linux test]# fsck.ext3 -ft /dev/fd0
查看fsck報錯的日誌
[root@server ~]# ls -l /var/log/fsck/
total 8
-rw-r----- 1 root adm 190 2011-06-09 10:03 checkfs
-rw-r----- 1 root adm 192 2011-06-09 10:03 checkroot
這兩個文件中會出現fsck的報錯信息。
[root@server ~]# more /var/log/fsck/checkfs
[root@server ~]# more /var/log/fsck/checkroot
查看當前的運行級別：
fsck.ext3掃描文件系統時一定要在單用戶模式、修複模式或把設備umount後進行。如果掃描運行中的系統，會造成系統文件損壞。
選擇在單用戶模式下運行
# runlevel ---查看運行級別
[root@server ~]# runlevel
N 2
#init 1 --單用戶模式（1 S），在轉換成單用戶模式時可能會需要輸入root密碼。
[root@server ~]# init 1
使用fsck.ext3對文件系統進行掃描、修複
[root@server ~]# fsck.ext3 -y /dev/sdb1 ---開始進入掃描、修正文件系統， sdb1必須umount
註意紅色方框，該位置需要輸入yes
fsck.ext3開始進入掃描、修正文件系統，這個過程時間比較長，中間有數次停頓的過程，只需等待即可，千萬不要以為死機而重啟伺服器。
fsck.ext3掃描、修正完文件系統後，根據提示可能需要重啟系統。如果沒有提示重啟系統，也需要reboot來重啟系統。
[root@server ~]# reboot ---重啟系統
在重啟系統的過程中，fsck會對文件系統進行掃描，如下：
fsck掃描完以後，會啟動到系統的登錄界面，不需要進行任何干涉。
再次重新啟動系統，系統可以正常啟動。
【Linux ext3 fsck一定要慎用】
不管是哪種文件系統，其根本目的都是相同的：如何把文件存在系統給定的區域里，如何有效地管理文件的讀與寫。為實現這樣的目的，驅動層需要完善、周密地應付附加在文件系統上的各種操作。這些操作通常不會是一條指令完成的，如果一個過程需要多條指令完成，在執行這些操作時，全部指令未完成的情況下產生中斷，那這個文件系統便會出現一致性錯誤(或者叫連續性錯誤)。
為了保證盡可以少的出現一致性錯誤，現在主流的文件系統都會設計成日誌型的。日誌型文件系統的主要特點就是把一個操作的所有指令執行過程都另外緩衝下來，如果全部執行完成再清除日誌標誌，如果操作沒有執行完成，可以在重新激活後通過日誌回溯或繼續完成。
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錯誤、需要重建樹、或大小不對等就不可再繼續下去了。
