☰

fsck 期间出现大量“多次声明的块”

tag-icon • tag-icon linux ubuntu fsck
fsck 期间出现大量“多次声明的块”

基本问题：

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 个文件共享，如果我正确理解了多重声明块的含义，这是一个矛盾。

答案1

需要多长时间取决于磁盘子系统的性能、正在修复的损坏等。

听起来文件系统损坏了不少。实际文件系统有多大？您说这是一个 100 GB 的文件，后来又说这是一个 VM 映像？这是 VM 服务器吗？还是您说的是 VirtualBox？

就我个人而言，如果花了超过一天的时间，而且损坏的肯定是一个文件，我会从备份中恢复该文件，如果有任何迹象表明问题仍在继续，则重新格式化并从备份中恢复，假设驱动器不是偶然出现故障。我对开始出现问题的文件系统有信心。如果驱动器本身没有出现故障，文件系统可能会出现普遍问题，直到它重新启动。

但那就是我。

答案2

看起来，造成如此大量时间浪费以及多个声明的块被零文件共享的谜团是由于 RAID 阵列性能下降造成的。

我一移除故障驱动器，fsck 就运行得更快了。仍有一些被多次声明的块，但它们很快就被修复了。

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

答案3

这发生在我 6 个磁盘、4.5TB ext4 文件系统的 RAID 阵列上。Linux 3.3.7-1-ARCH #1 SMP PREEMPT i686

我使用 rsync 将整个服务器同步到 ext4 上，这些文件是我主要获取这些多重声明块和重复 inode 消息的文件。

EXT4 安装选项

我做的几件事似乎有帮助，那就是确保 ext4 安装时带有 barrier 和 data=ordered 支持。

/dev/md5 /md5  ext4  defaults,noatime,nouser_xattr,stripe=1536,data=ordered  0 2

RAID 位图

我采取的另一个步骤是在 RAID 上启用位图。

mdadm --grow /dev/md5 --bitmap=internal

或者

mdadm --grow /dev/md5 --bitmap=/external/md5.bitmap

将 raid 位图和 ext4 日志都放在外部设备上似乎效果最好。

USB 自动暂停

过去，当我的驱动器进入自动挂起模式时，我曾遇到过此问题。在驱动器试图从挂起状态唤醒时写入（或尝试写入）似乎会导致这些问题严重。我所做的是使用以下命令在 USB 设备上完全禁用自动挂起：

usbcore.autosuspend=-1

EXT4 数据模式

从：http://kernel.org/doc/Documentation/filesystems/ext4.txt

有 3 种不同的数据模式：

  • 回写模式 在数据=回写模式下，ext4 根本不记录数据。此模式提供与 XFS、JFS 和 ReiserFS 在其默认模式（元数据日志）下类似的日志级别。崩溃+恢复可能会导致在崩溃前不久写入的文件中出现不正确的数据。此模式通常会提供最佳的 ext4 性能。

  • 有序模式 在 data=ordered 模式下，ext4 仅正式记录元数据，但它在逻辑上将与数据块相关的数据更改的元数据信息分组为一个称为事务的单元。当需要将新元数据写入磁盘时，将首先写入相关的数据块。一般来说，此模式的执行速度略慢于写回模式，但明显快于日志 > 模式。

  • 日志模式 data=journal 模式提供完整的数据和元数据日志记录。所有新数据首先写入日志，然后写入最终位置。如果发生崩溃，可以重播日志，使数据和元数据保持一致状态。此模式最慢，但当需要同时从磁盘读取和写入数据时，其性能优于所有其他模式。如果选择此数据日志记录模式，则 ext4 目前不支持延迟分配。

使用 Debugfs 修复

这有很好的例子可以解决：http://www.redhat.com/archives/ext3-users/2009-February/msg00021.html

答案4

您是否在使用不带日志的 ext2 或 ext4？在使用日志时，您不应该看到此类错误。

是的，多个文件共享的块是没有意义的。你应该在[电子邮件保护]邮件列表。

相关内容