我有几个带有 ext3 lv 的系统/，它们运行良好，直到进行 fsck 后，它们就不可恢复地损坏了。
我对修复这些系统有什么希望？另外，到底是哪里出了问题？
这些都是旧系统，最初是 2.6 centos-ish 盒子，带有几个单独的 ext3 逻辑卷： /、/var和/unused。它们被迁移到运行内核 3.4 的现代 Linux，方法是在/unused分区上安装，然后启动到新安装。一旦运行，旧的/和/varlvremove'd，新的根被重新命名，lvextend'ed 吸收了空间。据我所知，新的根调整2fs大小'会活在lvextend（这或许就是问题的根源。）
它们都运行良好，直到强制执行 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 下创建的，调整2fs大小'在 1.42.9-4 下，当前系统处于 CentOS 的旧版本（不要问）1.41.12-12。
答案1
明确回答您的问题：
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，复制并淘汰旧驱动器，或者至少运行制造商的诊断程序、擦除和重新格式化。