我的 ext4 系统分区有问题。我正在运行 17.04（从 16.10 升级），但问题已经出现在 16.10 中。
偶尔（最常见的是在将系统从挂起状态唤醒后）系统会因一堆 ext4 文件系统错误而崩溃。
现在在检查文件系统时
sudo fsck -n /dev/nvme0n1p2
fsck 声称文件系统是干净的
fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
Warning! /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/nvme0n1p2: clean, 434755/15089664 files, 46490132/60347136 blocks
但是，如果我强制检查，我会收到一大堆错误：
sudo fsck -nf /dev/nvme0n1p2
fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
Warning! /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix? no
Inode 131275 was part of the orphaned inode list. IGNORED.
Inode 135221 was part of the orphaned inode list. IGNORED.
Inode 135244 was part of the orphaned inode list. IGNORED.
Inode 135260 was part of the orphaned inode list. IGNORED.
Inode 135263 was part of the orphaned inode list. IGNORED.
Inode 135268 was part of the orphaned inode list. IGNORED.
Deleted inode 135272 has zero dtime. Fix? no
Inode 135274 was part of the orphaned inode list. IGNORED.
Inode 135384 was part of the orphaned inode list. IGNORED.
Inode 135396 was part of the orphaned inode list. IGNORED.
Inode 135697 was part of the orphaned inode list. IGNORED.
Inode 135711 was part of the orphaned inode list. IGNORED.
Inode 135713 was part of the orphaned inode list. IGNORED.
Inode 12059086 was part of the orphaned inode list. IGNORED.
Inode 12061077 was part of the orphaned inode list. IGNORED.
Inode 12062594 was part of the orphaned inode list. IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(40927357--40927367) -(40927563--40927569) -(40940652--40940653) -(40940676--40940681) -(48296964--48296970) -(48296978--48296984) -(48304145--48304165) -(48304315--48304321) -(48326677--48326690) -(48326733--48326739) -(48326775--48326781)
Fix? no
Free blocks count wrong (13857004, counted=13856542).
Fix? no
Inode bitmap differences: -131275 -135221 -135244 -135260 -135263 -135268 -135272 -135274 -135384 -135396 -135697 -135711 -135713 -12059086 -12061077 -12062594
Fix? no
Free inodes count wrong (14654909, counted=14654758).
Fix? no
/dev/nvme0n1p2: ********** WARNING: Filesystem still has errors **********
/dev/nvme0n1p2: 434755/15089664 files (0.3% non-contiguous), 46490132/60347136 blocks
现在我的问题是我无法修复这些错误，因为它是我的系统分区，我无法卸载。 但是当我从外部驱动器或恢复模式启动时，即使使用 -f ， fsck 也不会报告任何错误。但是，重新启动系统后，错误仍然存在。我目前不知如何才能修复文件系统。任何帮助将不胜感激。
如果您对当前使用 r/w 模式挂载的 ext4 文件系统强制执行文件系统检查fsck -nf <filesystem>，您将始终收到与您发布的错误消息类似的错误消息（损坏的孤立链表、删除的 inode ... dtime 为零） . 将其fsck -n <filesystem>报告为干净的事实在这里有点误导。
您在恢复模式下或从外部驱动器启动时没有看到这些错误的原因很简单，在这种情况下，有问题的文件系统没有安装在 r/w 模式下，甚至根本没有安装。
e2fsck的手册页还明确指出：
请注意，通常在挂载的文件系统上运行 e2fsck 是不安全的。唯一的例外是如果指定了 -n 选项，并且未指定 -c、-l 或 -L 选项。但是，即使这样做是安全的，如果挂载了文件系统，e2fsck 打印的结果也是无效的。如果 e2fsck 询问您是否应该检查已挂载的文件系统，唯一正确的答案是“否”。只有真正知道自己在做什么的专家才应该考虑以任何其他方式回答这个问题。
结论：如果您打算将-f标志用于 fsck，请确保您 100% 了解它的作用。特别是，在挂载的文件系统上使用它通常不是您想要的。
至于为什么从挂起状态唤醒时会出现 ext4 错误是一个完全不同的问题，而您似乎已经解决了这个问题。出于参考原因，我将在此处的评论中包含您自己发布的链接，因为它们有助于解决您的原始问题：