运行 CentOS 5.6 和 mdadm RAID1、2TB、3 个分区（启动、交换和根）。我的服务器出现内核崩溃，重启后，系统运行约 5-10 分钟，然后开始将 fsck 错误打印到控制台，并且根文件系统处于只读模式。
我重新启动进入单用户模式，卸载/分区并尝试运行
e2fsck -f /dev/md2
但它在第 1 阶段挂起超过 8 小时而没有更新。我注意到 RAID 正在重新同步（cat /proc/mdstat）——这会影响 e2fsck 吗？我在两个磁盘上运行了 smartctl，它们都恢复正常，所以我不认为这是磁盘问题，尽管我不知道是什么触发了 RAID 重建。
无论如何，在正在重新同步的 raid 设备上运行 e2fsck 是否存在问题？我可以做些什么让 fsck 退出第 1 阶段，或者获得更多有关进度的反馈？为什么错误指向 loop0 而不是实际设备之一？
答案1
(loop0) 应该能给我一些提示。问题不在于硬盘文件系统，而在于基于 RAM 的 tmpfs。我的 /tmp 目录是使用 tmpfs (/dev/shm) 挂载的
/usr/tmpDSK /tmp ext3
ext3 错误发生在基于 RAM 的 tmpfs 中。一旦我卸载 /tmp（必须使用 umount -l /tmp 强制卸载），错误就会消失，一切开始正常工作。问题仍然是为什么内存文件系统会出现 ext3 错误，但至少我可以正常运行。