昨天在两台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/

　　学一点，收获一点。学到的都是自己的！