基本问题：
fsck需要多久才能修复一个100GB（1700万块）的文件和多重声明的块？
问题的长版本：
在UPS发生故障之后，我遇到了一个Ubuntu 10.04服务器，它在初始启动时掉进了fsck。 这是正常的，购买通常约半小时的固定各种问题，同意提示足以让服务器回来。
不过，不是今天。 今天，我得到了一个巨大的数字列表滚动通过控制台matrix式好几分钟。 基本上是一线一线的：
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个文件共享。
那是2天前，现在还在运行。
所以，回到我原来的问题，这需要多长时间？ 这是一个失败的原因，有没有其他的方法来解决这个问题？ 我真正不明白的是，为什么100GB文件被报告为与0个文件共享，这是一个矛盾，如果我正确理解乘法声明块的含义。
需要多长时间取决于磁盘子系统的性能，修复的损坏等。
这听起来像是有一些体面的文件系统损坏。 实际的文件系统有多大？ 你说这是一个100 GB的文件，后来这是一个VM镜像？ 这是一个VM服务器？ 或者你在谈论virtualbox？
就个人而言，如果花了一天时间，损坏肯定是一个文件，我会从备份恢复文件，如果有任何迹象表明继续问题，重新格式化和从备份恢复，假设驱动器不巧合失败。 我对文件系统的信任问题开始变差。 如果驱动器本身没有失败，文件系统可能会有一个普遍的问题，直到它开始新鲜。
但那就是我。
这发生在6磁盘，4.5TB ext4文件系统的RAIDarrays上。 Linux 3.3.7-1-ARCH＃1 SMP PREEMPT i686
我使用rsync将整个服务器同步到ext4，这些是我主要获取这些multiply-claims-blocks和重复inode消息的文件。
我所做的一些似乎有用的事情是确保ext4正在安装屏障和数据=有序的支持。
/dev/md5 /md5 ext4 defaults,noatime,nouser_xattr,stripe=1536,data=ordered 0 2
我采取的另一个步骤是在RAID上启用位图。
mdadm --grow /dev/md5 --bitmap=internal
要么
mdadm --grow /dev/md5 --bitmap=/external/md5.bitmap
将raid位图和ext4日志位于外部设备上似乎工作得最好。
过去我遇到过这个问题，当我的硬盘进入autosuspend模式。 在他们试图从暂停的状态中醒来的时候给他们写信（或试图），似乎是造成这些问题的大好时机。 我所做的是禁用autosuspend在USB设备上：
usbcore.autosuspend=-1
来自： http ： //kernel.org/doc/Documentation/filesystems/ext4.txt
有3种不同的数据模式：
回写模式在data =回写模式下，ext4根本不logging数据。 此模式提供与XFS，JFS和ReiserFS类似的默认模式 – 元数据日志logging级别。 崩溃+恢复可能会导致不正确的数据出现在崩溃前不久写入的文件中。 这种模式通常会提供最好的ext4性能。
有序模式在数据=有序模式下，ext4仅正式logging元数据，但是逻辑上将与数据块相关的元数据信息与数据块分组到一个称为事务的单元中。 当需要将新的元数据写入磁盘时，首先写入关联的数据块。 一般来说，这种模式的执行速度比回写稍慢，但比journal>模式快得多。
日记模式数据=日记模式提供完整的数据和元数据日记。 所有新的数据首先被写入日志，然后到最终的位置。 在发生崩溃的情况下，可以重播日志，使数据和元数据达到一致的状态。 这种模式是最慢的，除了数据需要在超出所有其他模式的同时读取和写入磁盘。 如果select了这种数据logging模式，目前ext4没有延迟分配支持。
这有很好的例子来解决： http : //www.redhat.com/archives/ext3-users/2009-February/msg00021.html
似乎认为大量时间的原因以及零文件共享乘法声明块的奥秘是由于RAIDarrays性能下降造成的。
只要我删除了有故障的驱动器，fsck就更快了。 还有一些多重索赔的块，但他们很快就修好了。
在Ubuntu之前，我经历了退化的RAIDarrays，通常在grub阶段之后会有一个警告，但是在这种情况下并没有发生。
我想，我有一个类似的问题。 我有一个RAID0arrays中的2个硬盘。 有一次，我卸载设备后，手动执行了fsck 。 我的痛苦，我没有意识到，一个虚拟机仍在运行，并在我fsck'ed访问设备。 结果是大量的multiply claimed blocks ，因为我在进程中重新启动我的服务器，我认为它打破了超级块。 所以我甚至无法安装RAID。
我通过恢复超级块来解决这个问题，再次运行fsck并修复所有与“多次声明的块”无关的问题。 这花了我一些时间，我需要参加这个过程，告诉fsck不要修复“多重索赔块”。
之后，超级块被固定，我可以再次安装设备。 现在，我跑了几次fsck，并检查了哪些文件受到“多重声明块”的影响，通过点击ctrl^c来停止进程并简单地复制受影响的文件并删除原来的文件。
听起来很不寻常，但是它快速解决了我的问题，而且我的硬盘似乎是干净的（根据e2fsck ）。
如果有更好或更快的方法来解决这些问题，我很高兴听到他们的消息。
你使用ext2或ext4没有日志？ 你不应该看杂志的这种错误。
是的，拥有多个零文件共享的声明块是没有意义的。 您应该在[email protected]邮件列表上报告这个错误。