昨天在两台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/
学一点，收获一点。学到的都是自己的！