众所周知，你永远不应该对已挂载的分区进行 fsck。我可以理解，如果文件系统写给通过 fsck（例如，使用 -a 选项），但为什么不能在已安装的磁盘上运行只读检查？
答案1
从：
http://linux.die.net/man/8/fsck.ext3
“请注意，一般来说，e2fsck在已安装的文件系统上运行是不安全的。唯一的例外是如果-n指定了选项，并且未指定-c、-l或-L选项。但是，即使这样做是安全的，e2fsck如果文件系统已安装，则打印的结果无效。如果e2fsck询问您是否应该检查已安装的文件系统，唯一正确的答案是“否”。只有真正知道自己在做什么的专家才会考虑以其他方式回答这个问题。”
答案2
基本问题是文件系统检查器（通常）不是文件系统的一部分。相反，它是一个单独的程序，与内核中的文件系统代码读取和写入同一个磁盘。因此，如果您在活动文件系统上运行 fsck，则有两个不同的实体正在读取（并可能修改）相同的数据（磁盘），但它们不会以任何方式相互协调。正如其他人指出的那样，结果是大多数检查器都认为在它们运行时没有其他人更改文件系统元数据。如果内核文件系统更改了检查器没有预料到的内容，它们会感到困惑和/或报告虚假错误。
有一些文件系统带有专门设计为“在线”运行的检查器（即，在文件系统处于活动状态时）。较新版本的 FFS/UFS 通过针对文件系统的最新快照（只读、时间点、写时复制副本）运行 fsck 来实现此目的。如果它发现问题（例如分配位图中的不一致），它会通过系统调用来纠正这些问题，而不是写入原始磁盘。这使其能够与活动文件系统协调。
NetApp 的 WAFL 也有一个在线检查工具。可能还有其他的。
答案3
在以读写方式挂载的分区上运行 fsck 是愚蠢的，即使 fsck 处于只读模式。文件系统将在 fsck 下发生变化，并且 fsck 从文件系统缓存的内存数据将变为无效（因此 fsck 将看到不一致）。您可以在只读模式下在只读挂载的文件系统上运行 fsck 并获得有效结果。在只读挂载的文件系统上以读/写模式运行 fsck，如果 fsck 在运行过程中对文件系统进行了更改，则会导致内核看到其下的文件系统结构意外更改。这也很糟糕。
答案4
嗯，fsck 的目的是报告文件系统不一致，即违反不变量。
但是，许多此类检查涉及多个 FS 结构。如果有人正在修改 FS（写入数据），这些结构可能会暂时不同步。fsck 会将此视为不一致，即使它实际上不是问题。fsck 无法判断不一致是暂时的，还是需要修复的永久性问题。所以这不可能奏效（除非 FS 专门设计为允许在线检查。有些可以，但 ext3 不行）。