修复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/

  学一点,收获一点。学到的都是自己的!

上一篇:posix and system V IPC


下一篇:深度学习项目实战——“年龄预测”