fsck 期间出现大量“多重认领区块”

Question

基本问题：

fsck 需要多长时间才能修复具有多重声明块的 100GB（1700 万块）文件？

问题的长版本：

UPS 故障后，我遇到了一台 Ubuntu 10.04 服务器，该服务器在初始启动时陷入 fsck 状态。这是正常的，通常购买大约半小时通过同意提示修复各种问题就足以让服务器恢复。

不过今天不行。今天，我看到一个巨大的数字列表在控制台矩阵式上滚动了好几分钟。基本上是一行又一行：

Multiply-claimed blocks in inode xxxxxxxxx

不管怎样，经过几分钟的滚动，它终于平静下来，我得到了：

Pass 1C: Scanning directories for inodes with multiply-claimed blocks

其次是...

Pass 1D: Reconciling multiply-claimed blocks

..和..

(There are 32 inodes containing multiply-claimed blocks.)

这听起来并没有那么糟糕，但随后它开始检查一些文件，如下所示：

File /path/to/a/file

has 1 multiply-claimed block(s) shared with 1 file(s):

/path/to/another/file

Clone multiply-claimed blocks? yes

这个问题已经为我解答了，这个过程还在继续。然而，这花了非常非常长的时间。即使只是一个 2MB 的文件，也花了好几个小时。

之后，出现了类似的对话，但这次是针对一个100GB 的虚拟机映像文件，报告为超过 1700 万个多重声明的块，与 0 个文件共享。

那是两天前的事了，现在仍在运行。

那么，回到我最初的问题，这需要多长时间？这是一个失败的原因吗？是否有其他方法可以解决这个问题？我真正不明白的是为什么 100GB 文件被报告为与 0 个文件共享，如果我正确理解多重声明块的含义，这是一个矛盾。

Answer 1

人们认为，大量时间的原因以及零文件共享的多重声明块的神秘原因是 RAID 阵列降级的结果。

当我移除有故障的驱动器后，fsck 速度就快得多。仍然有一些被多重认领的区块，但很快就被修复了。

我之前在 Ubuntu 中遇到过 RAID 阵列降级的情况，通常在 grub 阶段之后会出现警告，但在本例中并没有发生这种情况。