暴力掉电导致reiserfs crash

这两天忙着定位一个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？还好调用有打印

prepare_error_buf 0x56/0x35b

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

static char *cpu_type(struct cpu_key *key)
{
     if (cpu_key_k_type(key) == TYPE_STAT_DATA)
          return "SD";
     if (cpu_key_k_type(key) == TYPE_DIRENTRY)
          return "DIR";
     if (cpu_key_k_type(key) == TYPE_DIRECT)
          return "DIRECT";
     if (cpu_key_k_type(key) == TYPE_INDIRECT)
          return "IND";
     return "UNKNOWN";
}
static inline loff_t cpu_key_k_type(const struct cpu_key *key)
{
     return key->on_disk_key.k_type;
}

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

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

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

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

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

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