☰

EXT3-fs 错误（设备 dm-10）

tag-icon • tag-icon rhel5 ext3
EXT3-fs 错误（设备 dm-10）

我收到以下日志错误：

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

有人可以帮忙吗？

答案1

您的文件系统可能直到现在才自动切换到只读模式。

这是你的文件系统的一般故障。可能是由于写入失败导致的。

如果您的文件系统仍可写，请将其挂载为只读 ( 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）。

如果您可以毫无问题地重新启动（即您暂时没有在 5000 公里外的合作伙伴关键任务服务器上工作），那么从只读救援系统的根 shell 进行此操作肯定不是一个坏做法。

您也可以计算出相同的数据丢失，尽管不必真正害怕这些神秘的错误消息，即使有这么多。您的文件系统可能只有少量损坏。

相关内容