EXT3 3-fs错误(设备dm-10)

Question

下面显示了这个日志错误：

Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159746
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159747
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159748
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159749
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159750
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159751
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_free_blocks_sb: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_reserve_inode_write: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_truncate: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_reserve_inode_write: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_orphan_del: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_reserve_inode_write: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_delete_inode: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_journal_start_sb: Detected aborted journal

有人能帮忙吗？

Answer 1

到目前为止，您的文件系统可能会自动切换到只读模式。

在fs中，这是一个普遍的失败。这可能是由写失败引起的。

如果fs还可以写，那么将其挂载到readonly (mount /the/fs/mount/path -o remount,ro)。如果您不能这样做，那么首先您必须杀死任何想要/可以在那里编写任何东西的进程(您可以使用lsof -n|grep /the/fs/mount/path找到它们)。

然后运行一个硬文件系统检查(e2fsck -f -p -C0 /dev/device/path)。如果您不喜欢按y一千次，那么也使用一个-y标志，而不是-p --尽管在本例中，您会自动对文件系统修复工具的每一个潜在的破坏性操作说“是”。

在此之后，您可以再次重装可写(mount /the/fs/mount/path -o remount,rw)。

如果您可以在没有问题的情况下重新启动(也就是说，您没有在您的parters任务关键服务器上工作5000公里)，那么从只读救援系统的根外壳进行这一操作肯定不是一种糟糕的做法。

你也可以用同样的数据损失来计算，尽管对这些神秘的错误信息没有任何真正的恐惧，即使有这么多。到目前为止，您的文件系统可能只有几处损坏。