我有几个系统有一个ext3 lv /可以正常工作直到fsck’d – 然后它们不可挽回地被破坏了.
我有什么希望修复这些系统,并且,另外,出了什么问题？
这些都是旧系统,最初是以2.6厘米为单位的盒子,有几个独立的ext3逻辑卷：/,/ var和/ unused.通过安装在/ unused分区上然后启动到新安装,它们被迁移到运行内核3.4的现代Linux.一旦运行,旧的/和/ var被删除,新的根被重命名并且lvextend’ed吸收空间.从我能够收集到的内容来看,新的root用户是在lvextend之后的resize2fs’d. (这可能是问题的根源.)
它们都运行良好,直到fsck被强制,此时fsck大肆抱怨并使系统无法启动(恐慌).很多错误,如：
Inode 12345 has INDEX_FL flag set but is not a directory Inode 67890,i_blocks is 1307617,should be 0. Inode 34567,i_size is 5616670468207675,should be 0. ... and on and on,followed by lots of multiply claimed inodes,sometimes with ... Error storing directory block information (inode=76543,block=0,num=98765432): Memory allocation Failed
对于上下文,原始分区是在CentOS的e2fsprogs-1.39-20下创建的,resize2fs在1.42.9-4下创建,当前系统是在CentOS的旧版本(不要问)1.41.12-12.
解决方法
要明确回答您的问题：
Q: What hope do I have of repairing these systems? A: Quite good since the fs is readable,but I'd plan on abandoning the current hard drive(s). Q: Separately,what went wrong? A: Unless you can definitively diagnose a hardware error (likely),you'll probably never kNow. You don't mention if you've looked for low-level I/O errors in the system log.
由于文件系统在fsck之前工作,我会用新的物理卷(一个实际的新的,可靠的硬盘驱动器)扩展VG,在新的PV上定义一个新的LV,复制并淘汰旧的驱动器,或者至少运行制造商的诊断,擦拭和重新格式化.
