众所周知，你永远不应该挂载一个挂载的分区。 我可以理解，如果通过fsck 写入文件系统（例如，使用-a选项），这很容易导致损坏，但是为什么不能在已挂载的磁盘上运行只读检查？
从：
http://linux.die.net/man/8/fsck.ext3
“请注意，通常在挂载的文件系统上运行e2fsck是不安全的，唯一的例外是如果指定了-n选项，并且没有指定-c，-l或-L选项，但即使它是安全的如果文件系统被挂载，那么e2fsck打印的结果是无效的。如果e2fsck询问你是否应该检查挂载的文件系统，唯一正确的答案是“否”。只有真正知道是什么的专家他们正在做的事情应该考虑以任何其他方式回答这个问题。“
基本的问题是文件系统检查器（通常）不是文件系统的一部分。 相反，它是一个单独的程序，可以读写内核中文件系统代码所在的磁盘。 因此，如果在活动文件系统上运行fsck，则有两个不同的实体正在读取（并可能修改）相同的数据（磁盘），但它们并不以任何方式相互协调。 正如其他人所指出的那样，结果是大多数检查人员希望没有其他人在运行时更改文件系统元数据。 如果内核文件系统改变了检查器不期望的内容，他们会感到困惑和/或报告虚假错误。
有几个带有检查器的文件系统被明确devise为“联机”运行（即文件系统处于活动状态时）。 较新版本的FFS / UFS通过针对最近的文件系统快照（只读，时间点，写时复制副本）运行fsck来执行此操作。 如果发现问题（例如分配位图中的不一致），则通过系统调用而不是写入原始磁盘来纠正这些问题。 这可以让它与活动文件系统协调。
NetApp的WAFL也有一个在线检查工具。 有可能是其他人。
在挂载读写的分区上运行fsck将是愚蠢的，即使fsck处于只读模式。 文件系统将在fsck下更改，而fsck从文件系统caching的内存数据将变为无效（因此fsck将会看到不一致）。 您可以在只读模式下以只读方式运行fsck，并获得有效的结果。 在读取/挂载文件系统上以读/写模式运行fsck会导致内核看到文件系统结构在其下面意外改变，这也是不好的。
除了可能会导致你的I / O吞吐量下降之外，如果文件系统在fsck被修改的时候，fsck无法跟踪这些变化并报告不稳定的情况。
一些像XFS这样的文件系统可以让您在文件系统读写时执行一致性检查，同时警告可能会报告错误的错误。 xfs_checkbuild议在执行检查之前将文件系统卸载或挂载为只读。
那么，fsck的意义在于报告文件系统的不一致性，即违反了不variables。
然而，许多这些检查涉及不止一个FS结构。 如果有人正在修改FS（写入数据），这些结构可能暂时不同步。 fsck会认为这是不一致的，即使这不是一个真正的问题。 fsck无法判断不一致是否只是暂时的，或是需要修复的永久性问题。 所以这不可能工作（除非一个FS是专门devise允许在线检查。有些是，但是ext3不）。
那么，你可以。 fsck -n / dev / sda1将至less在ext3上做到这一点。 我只是testing它:)
你可以，就像你可以把手伸进一个移动的搅拌器里一样，也可能不会伤害到自己，或者就像你可以从一座高楼跳下来一样，瞄准下面人行道上的一小堆靠垫。
但是，为什么你要testing自己的死亡率呢？ 因为当你发现邮件服务器现在无法识别根驱动器时，你的老板肯定会再次testing它。