我的 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
现在我的问题是我无法修复这些错误，因为它是我的系统分区，我无法卸载它。 但是当我从外部驱动器启动或处于恢复模式时，fsck 不会报告任何错误，即使使用 -f。但是，重启系统后，错误仍然存在。我目前不知道如何修复文件系统。如能得到任何帮助，我将不胜感激。
答案1
如果您强制对当前使用 以 r/w 模式挂载的 ext4 文件系统进行文件系统检查fsck -nf <filesystem>，那么您将始终收到类似您发布的错误消息（损坏的孤立链接列表，已删除的 inode ... dtime 为零）。将其报告为干净的事实fsck -n <filesystem>在这里有点误导。
您在恢复模式或从外部驱动器启动时没有看到这些错误的原因很简单，在这种情况下，相关的文件系统没有以 r/w 模式安装，甚至根本没有安装。
手册页e2fsck还明确指出：
请注意，一般来说，在已挂载的文件系统上运行 e2fsck 是不安全的。唯一的例外是指定了 -n 选项，而未指定 -c、-l 或 -L 选项。但是，即使这样做是安全的，如果文件系统已挂载，e2fsck 打印的结果也是无效的。如果 e2fsck 询问您是否应该检查已挂载的文件系统，唯一正确的答案是“否”。只有真正知道自己在做什么的专家才会考虑以其他方式回答这个问题。
结论：如果您打算使用-ffsck 的标志，请确保您完全理解它的作用。特别是，在已安装的文件系统上使用它通常不是您想要的。
至于为什么从挂起状态唤醒时会出现 ext4 错误，这是一个完全不同的问题，您似乎已经解决了这个问题。出于参考原因，我将在此处的评论中包含您自己发布的链接，因为它们有助于解决您的原始问题：