我的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-mode挂载的ext4文件系统进行文件系统检查fsck -nf <filesystem>，则您将始终收到错误消息，如您发布的消息（损坏的孤儿链表，Delete索引节点...的dtime为零） 。将其fsck -n <filesystem>报告为干净的事实在这里有点误导。
在恢复模式下或从外部驱动器启动时看不到这些错误的原因很简单，在这种情况下，相关文件系统没有以r / w模式挂载，甚至根本没有挂载。
e2fsck的手册页还明确指出：
请注意，通常在已挂载的文件系统上运行e2fsck是不安全的。唯一的例外是，如果指定了-n选项，而未指定-c，-l或-L选项。但是，即使这样做是安全的，如果挂载了文件系统，e2fsck打印的结果也是无效的。如果e2fsck询问您是否应该检查已挂载的文件系统，则唯一正确的答案是``否''。只有真正知道自己在做什么的专家才应考虑以任何其他方式回答这个问题。
结论：如果您打算将-f标志用于fsck，请确保您100％理解它的作用。特别是，通常不需要在已安装的文件系统上使用它。
至于为什么从暂停唤醒时出现ext4错误是一个完全不同的问题，您似乎已经解决了。出于参考原因，我将在此处添加您在评论中发布的链接，因为它们有助于解决您的原始问题：
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句