这两天忙着定位一个reiserfs文件系统的问题,事情确是很简单:产品的服务器在测试业务时直接将服务器暴力下电了,结果挂载的磁阵就悲剧了,业内所知受部门物料成本限制,实验室的环境都是拼凑的,很神奇的是这个磁阵的电池被拔掉了,再次上电的时候OS就很规律的7min oops一次,问题很快(内核panic)就送到了额们组。当时自己正郁闷着写了一天的ppt被老大的老大委婉劝说换一个模板时,看到问题立即精神抖擞的奔着oops的message打印去了

BUG: unable to handle kernel NULL pointer dereference at 0x0000000F

愣住了,不像文件系统问题,但reiserfs_warning一堆,栈打印到了prepare_error_buf就木有了,从前面的看代码怎么走到do_page_fault?还好调用有打印

立即把内核反编译了一把,竟然木有函数,只好把reiserfs.ko反编译了,终于确定死在cpu_type里的第一行

代码看不出啥了,k_type的复制简单明了,看不出指针啥问题,没啥搞了,只好架上kdump,可每次转储core时总是不识别reiserfs,然后panic,搞了一下午,眼看明天就把巨丑的ppt汇报,忙的要死,测试人员还搞了一个致命问题的定性,顿时相关部门就鸭梨山大了,就连一直打酱油的磁阵部门也忙活起来,一个晚上给出了结论:

实验室人员操作不当,拔掉磁阵电池,而进行暴力下电,导致文件系统损害,fsck重新修复文件系统即可,OVER。

感觉自己就白痴了两天一般。 想想自己也可以这样交差,为什么这么痛苦的搞来搞去的呢。 很多情况下技术人员会用技术说话,事实上确是商业(部门工作)策略才是真正起作用的力量。商业不需要技术上的深奥解释,只需要直接的利益获取。

正如之前的预想一样,真正想提升自己的bugfix能力,需要去对应的技术部门,业务部门为什么要进行kernel开发,需要为KVM提交代码么,研发投入还不如直接买vmvare的解决方案来的划算,只有当无数业务通用之后类似阿里云才可能去IOE,一般的技术公司搞类似的技术运动早就倒闭了。


暴力掉电导致reiserfs crash来自于OenHan

链接为:http://oenhan.com/reiserfs-crash-panic

2 对 “暴力掉电导致reiserfs crash”的想法;

    1. @STAR GUO 还有用reiserfs啊,是小文件,其实所谓的小文件优势可以忽略了,各种bug维护成本巨大,好好劝劝你们领导放弃治疗吧
      debug就是当时但是磁盘阵列的电池掉了,被用户拔光纤导致元数据不一致的。

发表评论