修復FREEBSD上的UFS文件系統

　　昨天在兩臺FreeBSD上配置好Heartbeat服務（兩臺機器是用網線連通的，做爲Heartbeat的兩個節點），啓動服務時Heartbeat檢測到crmd守護進程沒起來，於是它就嘗試重啓兩臺機器以啓動crmd守護進程。不料重啓的過程文件系統出問題了。

　　錯誤的信息是這樣的：

　　　　　　panic: ufs_dirbad:  /: bad dir ino 321044 at offset 512: mangled entry 

　　　　　　cpuid=0

　　　　　　之後是一堆的內核棧空間的出錯信息，並提示，系統15秒後自動啓動。

　　既然是文件系統出錯，又是ufs文件系統，當然第一時間想到的是fsck。於是我掛起了Live CD，對系統分區進行了fsck -y  /dev/ada0p2修復（很盲目，沒辦法，咱懂得的也就這麼多:-））再次啓動系統，傻了眼，起不來！老樣子！。

　　沒辦法，只好祭起大招來！上網google一把！看看老外大牛的說法。大牛說了，這種事情發生的機率很少，十年來他才遇見三次。（太榮幸了，我一天之內同時遇見二次！）具體的原因是由於某些硬件引起的（看來是沒法查了）。不過幸運的是大牛給了不少的解決方法，我先嚐試了幾個，但很不幸的是都沒能成功！:-( 還好也有點收穫，看到大牛介紹的利用fsdb進行文件系統調試，覺得這個有點技術含量哦！

　　學技術的人看到了有技術含量的東西，不免有點熱血沸騰了！於是按照他的說法做了起來：（反正也沒招，不成功咱也能找點見識啊！）

　　1　　先啓動機器，進入FreeBSD的單用戶模式。

　　2　　直接對分區執行fsdb：fsdb /dev/ada0p2

　　3　　執行完上述命令後進入的是一個類似gdb的調試界面。

　　4　　執行inode 321044（321044是錯誤的inode節點號)，界面報出了一大堆信息。（呵呵，咱這水平，還看不懂！）

　　5　　不管三七二十一，執行clir 321044 （我這是莽夫的行爲，千萬別學我，至少要做個備份了再幹）

　　6　　執行quit，退出fsdb。fsdb提示需要執行fsck檢查文件系統。

　　7　　執行fsck命令，系統自動找着問題分區，詢問進行日誌修復（鍵入y)

　　8　　重啓系統

　　在重啓系統的時候系統又報了文件系統出錯，不過這回是進入單用戶模式（看來有點效果了），好吧，老辦法，進行一次fsck -y /dev/ada0p2再重啓系統， 這回沒有報錯了，且能進入login界面了！哈哈！

　　fsdb，有點意思！

　　老外網址：http://phaq.phunsites.net/2007/07/01/ufs_dirbad-panic-with-mangled-entries-in-ufs/