为什么不能fsck挂载的分区？

众所周知，您永远不要对已挂载的分区执行fckck操作。我可以理解，如果文件系统由fsck 写入（例如，使用-a选项），那么这很容易导致损坏，但是为什么不能在已安装的磁盘上运行只读检查呢？

从：

http://linux.die.net/man/8/fsck.ext3

“但是，一般来说它是不是安全运行e2fsck上安装的文件系统。唯一的例外是，如果-n指定的选项，和-c，-l或-L不指定的选项。然而，即使它是安全的话，通过打印结果e2fsck是如果已挂载文件系统，则无效。如果e2fsck询问是否应检查已挂载的文件系统，则唯一正确的答案是“否”。只有真正知道自己在做什么的专家才应考虑以其他方式回答此问题。方式。 ”

基本问题是文件系统检查器（通常）不属于文件系统。相反，它是一个单独的程序，与内核中的文件系统代码读写相同的磁盘。结果，如果在活动文件系统上运行fsck，则您有两个不同的实体正在读取（并可能修改）相同的数据（磁盘），但它们之间没有任何协调关系。正如其他人指出的那样，结果是大多数检查者期望运行时其他任何人都没有更改文件系统元数据。如果内核文件系统更改了检查程序无法预期的内容，它们将变得混乱和/或报告虚假错误。

有一些带有检查器的文件系统被明确设计为“在线”运行（即，在文件系统处于活动状态时）。较新版本的FFS / UFS通过对文件系统的最新快照（只读，时间点，写时复制副本）运行fsck来实现此目的。如果发现问题，例如分配位图中的不一致，它将通过系统调用而不是通过写入原始磁盘来纠正它们。这样可以使其与活动文件系统协调。

NetApp的WAFL还具有一个在线检查工具。可能还有其他人。

即使将fsck设置为只读模式，在以挂载方式安装的分区上运行fsck也很愚蠢。文件系统将在fsck下更改，并且fsck从文件系统缓存的内存中数据将变为无效（因此fsck将出现不一致）。您可以在只读模式下的只读挂载文件系统上运行fsck并获得有效结果。如果fsck在其运行过程中对文件系统进行了更改，则在只读安装的文件系统上以读/写模式运行fsck会导致内核看到其下的文件系统结构发生意外更改。那也将是不好的。

除了可能会杀死您的I / O吞吐量这一事实之外，如果在fsck期间修改文件系统，则fsck无法跟踪更改并报告不一致性。

一些文件系统（例如XFS）使您可以在以读写方式安装文件系统时执行一致性检查，但要注意的是，很可能会报告虚假错误。xfs_check建议在执行检查之前将文件系统卸载或以只读方式装载。

好吧，fsck的目的是报告文件系统的不一致性，这是不可变的。

但是，其中许多检查涉及多个FS结构。如果有人正在修改FS（写入数据），则这些结构可能会暂时不同步。fsck会将其视为不一致，即使这并不是真正的问题。fsck无法判断不一致是暂时的还是需要修复的永久性问题。因此，这可能行不通（除非FS专为允许进行在线检查而设计。有些可以，但ext3不能）。

好吧，可以。fsck -n / dev / sda1至少在ext3上会做到这一点。我刚测试过:)

您可以，就像可以将手伸入移动的搅拌器中而不会受伤一样，也可以像从高楼上跳跃一样，瞄准在人行道上铺设的一小堆垫子。

但是，除了测试您自己的死亡率之外，您为什么还要这么做？因为您的老板肯定会在发现原因后再次进行测试，因此邮件服务器现在无法识别根驱动器。