Linux檔案系統破壞，導致系統無法啟動解決辦法

Linux下普遍採用的是ext3檔案系統，ext3是一個具有日誌記錄功能的日誌檔案系統，可以進行簡單的容錯和恢復，但是在一個高負荷讀寫的ext3檔案系統下，如果突然發生掉電，就很有可能發生檔案系統內部結構不一致，導致檔案系統破壞。

Linux在啟動時，會自動去分析和檢查系統分割槽，如果發現檔案系統有簡單的錯誤，會自動修復，如果檔案系統破壞比較嚴重，系統無法完成修復時，系統就會自動進入單使用者模式下或者出現一個互動介面，提示使用者介入手動修復，現象類似下面所示：
checking root filesystem
/dev/sdb5 contains a file system with errors, check forced
/dev/sdb5:
Unattached inode 68338812
/dev/sdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
(i.e., without -a or -p options)
FAILED
/contains a file system with errors check forced
an eror occurred during the file system check
****dropping you to a shell;the system will reboot
****when you leave the shell
Press enter for maintenance
(or type Control-D to continue):
give root password for maintenance
從這個錯誤可以看出，系統根分割槽檔案系統出現了問題，系統在啟動時無法自動修復，然後進入到了一個互動介面，提示使用者進行系統修復。
這個問題發生的機率很高，引起這個問題的主要原因就是系統突然掉電，引起檔案系統結構不一致。一般情況下解決此問題的辦法是採用fsck命令，進行強制修復。
根據上面的錯誤提示，當按下“Control-D”組合鍵後系統自動重啟，當輸入root密碼後進入系統修復模式，在修復模式下，可以執行fsck命令，具體操作過程如下：
[root@localhost /]#umount /dev/sdb5
[root@localhost /]#fsck .ext3 -y  /dev/sdb5
e2fsck 1.39 (29-May-2006)
/ contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 6833812 ref count is 2, should be 1.  Fix? yes
Unattached inode 6833812
Connect to /lost+found? yes
Inode 6833812 ref count is 2, should be 1.  Fix? yes
Pass 5: Checking group summary information
Block bitmap differences:  -(519--529) -9273
Fix? yes
…… ……
/: ***** FILE SYSTEM WAS MODIFIED *****
/: 19/128520 files (15.8% non-contiguous), 46034/514048 blocks
        上面就是fsck修復受損檔案系統的過程，fsck詳細用法在本書第四章有詳細的講述，這裡不在多講。需要注意的是，在執行fsck的時候，一定要先解除安裝要修復的分割槽，然後再執行修復操作，切記！

很好很好！！！轉來自己看看！！