意外运行fsck手动redhat

Question

在完成文件系统大小调整之前，我错误地重新启动了服务器。下面是在重新启动之前成功运行的命令：

lvresize -L -400GB /dev/mapper/vg_yavin-lv_home

在启动时，我会得到这个错误

/dev/mapper/vg_yavin-lv_home: UNEXPECTED INCONSITENCY run fsck MANUALLY

当我尝试fsck -y /dev/mapper/vg_yavin-lv_home时，我得到了以下信息：

e2fsck 1.41.12 (17-May-2010)
Error reading block 63471616 (Invalid argument).  Ignore error? yes

Force rewrite? yes

Error writing block 63471616 (Invalid argument).  Ignore error? yes

Superblock has an invalid journal (inode 8).
Clear? yes

*** ext3 journal has been deleted - filesystem is now ext2 only ***

Superblock has_journal flag is clear, but a journal inode is present.
Clear? yes

The filesystem size (according to the superblock) is 127047680 blocks
The physical size of the device is 22190080 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes

Error writing block 63471616 (Invalid argument).  Ignore error? yes

如果我在fstab中注释掉该文件系统，我可以启动，但是有什么方法可以恢复该文件系统吗？

Answer 1

ProTip:当它说

手动运行fsck

它的真正意思是

在交互模式下运行fsck并对输出进行评估以决定您想要做什么

而不是“盲目地使用-y，因为其他人似乎都是这么做的，它不会伤害任何东西”。

fsck -y可能具有破坏性。这就是为什么它不是默认行为的原因。

听起来您有一些相当严重的损坏(“错误读取块63471616”位让我认为可能是物理磁盘损坏)，坦率地说，fsck可能使情况变得更糟。

如果您有备份，现在就是使用它们的时候了。如果不是，而且数据很重要，我将对分区进行图像处理(您可以尝试在映像上运行调试器之类的恢复工具)。

最终，您可能希望只使用newfs (或mkextfs，无论与Linux等效)分区--如果您确定这不是由于物理磁盘故障造成的。

Answer 2

注意，下面的方法将不会得到您的数据。它可能会还原卷组元数据。您可以随时阅读产品指南中的lvm文档。它详细解释了我将要讲的命令。

注释掉f中的fs，然后引导。现在，找到运行lvresize的VG。我想是vg_yavin。

运行这个

vgcfgrestore --list <VG-NAME>

这将在任何重要操作完成之前给出VG上的断点列表。您必须找到与您的lvresize操作相对应的文件。理论上这应该是最近的一次。

在那个文件上运行

 vgcfgrestore --file /etc/lvm/archive/<file-name> <VG-NAME>

这将在lvresize之前恢复VG的元数据。

正常启动并查看它是否有效。

在错误消息中，fs的默认超级块已损坏。尝试使用备份超级块启动，如果您有一个工作的dumpe2fs输出，这些超级块应该会出现。然后

e2fsck -b <backup_sb> <disk-name>

但是，取决于腐败和当前fs的严重程度，这都是一种可能性。

Answer 3

考虑到您的最后一个问题，您可能只需要按指示运行resize2fs。目前，您的卷缩小了，但是文件系统没有缩小以与其匹配。这样做，再次运行fsck，希望您会没事。