一点一滴努力,满仓满谷收成

我们一台IBM主机,正常重启后一4TB文件系统无法mount,提示需要fsck。这个文件系统有7000万个inode，IBM工程师说他们在中国移动刚fsck一400万inode的文件系统，用了2个小时，按这个估计一下我们需要34个小时，可业务急需恢复。。
先建了一个新的文件系统让应用部分做业务恢复，另一路径以各种渠道看IBM是不是有方法可以跳过fsck把文件系统mount上，把最新的程序及参数配置取出来。IBM二线、三线工程师均给出的答案是没有办法，只能死等。
山东同事说他们出过几次这样的问题，当文件系统超过2TB,这样问题发生的概率会很高，IBM二线工程师说中国移动也发生过N次这样的问题。

fsck要做5步,90%之上的时间消耗在前两步。


# fsck -y /dev/fslv01
The current volume is: /dev/fslv01
Primary superblock is valid.
*** Phase 1 – Initial inode scan
*** Phase 2 – Process remaining directories
*** Phase 3 – Process remaining files
*** Phase 4 – Check and repair inode allocation map
File system inode map is corrupt (FIXED)
Superblock marked dirty because repairs are about to be written.
*** Phase 5 – Check and repair block allocation map
Block allocation map is corrupt (FIXED)
File system is clean.
Superblock is marked dirty (FIXED)
All observed inconsistencies have been repaired.

用procstack会发现，Phase 1做inode扫描，相应stack未记录下来。
Phase 2校验层次结构，相应stack如下：

procstack 6029670
6029670: /sbin/helpers/jfs2/fsck64 -f -y /dev/gathermplv
0x000000000000f480 memmove64_overlay() + 0x80
0x0000000100059030 iget(inode*,long)(??, ??) + 0x2f0
0x00000001000140dc verify_hierarchies(wfset_t*,unsigned long)(??, ??) + 0x13c
0x0000000100022a84 fsck(char*)(??) + 0x13c4
0x00000001000257c0 main(??, ??) + 0x240
0x0000000100000220 __start() + 0x70

我们这个4TB,7000万个结点的文件系统fsck时间为16个小时，比预想的要快。

经过这次问题有几点感想如下：
1、应用程序及参数配置数据要及时往版本服务器备份。不光是源代码，可执行程序也需要备，不然准备编译环境及重新编译需要时间。
2、文件系统不应过大，比如超过2TB,不然fsck时间会很长，目前无好办法，只能死等。
3、shutdown主机前要做sync,要把文件系统特别是大文件系统umount下来，小心驶得万年船。