☰

无法从 Linux RAID6 阵列挂载 XFS 文件系统（“日志不一致”）

tag-icon • tag-icon linux raid mount mdadm xfs
无法从 Linux RAID6 阵列挂载 XFS 文件系统（“日志不一致”）

第一次发帖 — 如果我的礼仪不正确，我深感抱歉。

我有一个带有 30 个磁盘的 ~200TB RAID6 阵列，但我无法安装它 - 我只收到消息：

mount /dev/md125 /export/models
mount:/dev/md125: can't read superblock

如果我运行mdadm --detail它，它会显示为干净的：

/dev/md125:
           Version : 1.2
     Creation Time : Wed Sep 13 15:09:40 2017
        Raid Level : raid6
        Array Size : 218789036032 (203.76 TiB 224.04 TB)
     Used Dev Size : 7813894144 (7.28 TiB 8.00 TB)
      Raid Devices : 30
     Total Devices : 30
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Fri May 20 23:54:52 2022
             State : clean
    Active Devices : 30
   Working Devices : 30
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : bitmap

              Name : localhost.localdomain:SW-RAID6
              UUID : f9b65f55:5f257add:1140ccc0:46ca6c19
            Events : 1152436

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1      65      161        1      active sync   /dev/sdaa1
       2      65      177        2      active sync   /dev/sdab1
       3      65      193        3      active sync   /dev/sdac1
       4      65      209        4      active sync   /dev/sdad1
       5       8       17        5      active sync   /dev/sdb1
       6       8       33        6      active sync   /dev/sdc1
       7       8       49        7      active sync   /dev/sdd1
       8       8       65        8      active sync   /dev/sde1
       9       8       81        9      active sync   /dev/sdf1
      10       8       97       10      active sync   /dev/sdg1
      11       8      113       11      active sync   /dev/sdh1
      12       8      129       12      active sync   /dev/sdi1
      13       8      145       13      active sync   /dev/sdj1
      14       8      161       14      active sync   /dev/sdk1
      15       8      177       15      active sync   /dev/sdl1
      16       8      193       16      active sync   /dev/sdm1
      17       8      209       17      active sync   /dev/sdn1
      18       8      225       18      active sync   /dev/sdo1
      19       8      241       19      active sync   /dev/sdp1
      20      65        1       20      active sync   /dev/sdq1
      21      65       17       21      active sync   /dev/sdr1
      22      65       33       22      active sync   /dev/sds1
      23      65       49       23      active sync   /dev/sdt1
      24      65       65       24      active sync   /dev/sdu1
      25      65       81       25      active sync   /dev/sdv1
      26      65       97       26      active sync   /dev/sdw1
      27      65      113       27      active sync   /dev/sdx1
      28      65      129       28      active sync   /dev/sdy1
      29      65      145       29      active sync   /dev/sdz1

cat /proc/stat显示：

[root@knox ~]# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md125 : active raid6 sdo1[18] sdh1[11] sdad1[4] sdd1[7] sdb1[5] sdi1[12] sdt1[23] sdr1[21] sdp1[19] sdx1[27] sdg1[10] sdn1[17] sdm1[16] sdab1[2] sdu1[24] sdl1[15] sde1[8] sdf1[9] sdw1[26] sdc1[6] sdq1[20] sdy1[28] sds1[22] sdv1[25] sdac1[3] sdz1[29] sdaa1[1] sda1[0] sdj1[13] sdk1[14]
      218789036032 blocks super 1.2 level 6, 512k chunk, algorithm 2 [30/30] [UUUUUUUUUUUUUUUUUUUUUUUUUUUUUU]
      bitmap: 0/59 pages [0KB], 65536KB chunk

md126 : active raid1 sdae3[0] sdaf2[1]
      976832 blocks super 1.0 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md127 : active raid1 sdaf1[1] sdae1[0]
      100554752 blocks super 1.2 [2/2] [UU]
      bitmap: 1/1 pages [4KB], 65536KB chunk

unused devices: <none>

Examine在各个设备上也显示为健康（我没有包括所有结果，因为它会占用太多空间，但它们都与这个相同）：

/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : f9b65f55:5f257add:1140ccc0:46ca6c19
           Name : localhost.localdomain:SW-RAID6
  Creation Time : Wed Sep 13 15:09:40 2017
     Raid Level : raid6
   Raid Devices : 30

 Avail Dev Size : 15627788288 sectors (7.28 TiB 8.00 TB)
     Array Size : 218789036032 KiB (203.76 TiB 224.04 TB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262056 sectors, after=0 sectors
          State : clean
    Device UUID : 917e739e:36fa7cf6:c618d73c:43fb7dec

Internal Bitmap : 8 sectors from superblock
    Update Time : Fri May 20 23:54:52 2022
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 2b5e9556 - correct
         Events : 1152436

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ('A' == active, '.' == missing, 'R' == replacing)

dmesg 中的相关条目显示：

[13297.001208] XFS (md125): Mounting V5 Filesystem
[13297.008854] XFS (md125): Log inconsistent (didn't find previous header)
[13297.008874] XFS (md125): failed to find log head
[13297.008878] XFS (md125): log mount/recovery failed: error -5
[13297.008934] XFS (md125): log mount failed

这件事的背景相当长且复杂，但简而言之，我试图通过添加额外的磁盘来扩大阵列，但操作被中断了。我最终通过将其重新调整为原来的 30 个磁盘（花了整整两周时间！）重建了阵列，但现在它不想安装。

不幸的是，它没有备份（我的意思是，你把 200TB 备份到哪里了？！？！）这里本来不应该存储任何有价值的东西，但是，不管怎样，人类都存储了一些重要的东西。

我已经看过了，xfs_repair但不确定是否应该在 RAID 阵列（md125）或单个 sd* 设备上运行它。

谢谢

更新（这一切背后的历史）：

该设备是 SuperMicro 服务器，运行 CentOS 7 (3.10.0-1160.11.1.e17.x86_64)，mdadm 版本为 4.1 – 2018-10-01，配有 30 x 8TB 磁盘，采用 RAID6 配置。它还在 2 个 RAID1 阵列上具有启动和根目录 - RAID6 阵列仅用于数据。它的空间不足，因此我们决定向阵列添加更多驱动器（它总共可以容纳 45 个驱动器）。

由于阵列中的原始磁盘是 4kN 驱动器，而提供的设备是 512e，因此需要使用 sg_format 重新格式化它们以进行转换（Western Digital 支持的程序）。我从一个磁盘开始进行测试。不幸的是，这个过程在中途被打断了，所以我重新启动它并完成了 OK，差不多——它确实将磁盘转换为 4096k，但确实抛出了一个或两个 I/O 错误，但它们似乎并不太令人担忧，我想，如果有问题，它会在接下来的几个步骤中显示出来。后来我发现了 dmesg 日志，它表明 I/O 错误比我想象的要多得多。

无论如何，由于 sg_format 似乎已完成，我进入下一个阶段，即使用以下命令对磁盘进行分区

     parted -a optimal /dev/sd<x>
     (parted) mklabel msdos
     (parted) mkpart primary 2048s 100% (need to check that the start is correct)
     (parted) align-check optimal 1 (verify alignment of partition 1)
     (parted) set 1 raid on (set the FLAG to RAID)
     (parted) print

然后我将新磁盘添加到阵列：

     mdadm --add /dev/md125 /dev/sd<x>

并且一切顺利完成。

然后我继续扩大阵列：

     mdadm --grow --raid-devices=31 --backup-file=/grow_md125.bak /dev/md125

我使用 cat /proc/mdstat 监控了这一点，它显示它正在重塑，但速度为 0K/秒，并且重塑没有从 0% 开始进展。

大约 12 小时后，由于重塑过程还没有从 0% 进展，我寻找了中止它的方法，例如 mdadm --stop /dev/md125，但没有奏效，所以我最终重新启动了服务器

服务器进入紧急模式。

我能够以 root 身份登录，但是 RAID6 阵列卡在重塑状态。

然后我尝试了一下mdadm --assemble --update=revert-reshape --backup-file=/grow_md125.bak --verbose --uuid= f9b65f55:5f257add:1140ccc0:46ca6c19 /dev/md125，结果如下：

     mdadm: No super block found on /dev/sde (Expected magic a92b4efc, got <varying numbers>
     mdadm: No RAID super block on /dev/sde
     .
     .
     mdadm: /dev/sde1 is identified as a member of /dev/md125, slot 6
     .
     .
     mdadm: /dev/md125 has an active reshape - checking if critical section needs to be restored
     mdadm: No backup metadata on /grow_md125.back
     mdadm: Failed to find backup of critical section
     mdadm: Failed to restore critical section for reshape, sorry.

我尝试了包括所有在内的不同变化，但mdadm --assemble --invalid-backup --force都无济于事。

此时我也移除了可疑磁盘，但这并没有什么变化。

但我最接近修复这个问题的方法是运行mdadm /dev/md125 --assemble --invalid-backup --backup-file=/grow_md125.bak --verbose /dev/sdc1 /dev/sdd1 ....... /dev/sdaf1并产生以下结果：

     mdadm: /dev/sdaf1 is identified as a member of /dev/md125, slot 4.
     mdadm: /dev/md125 has an active reshape - checking if critical section needs to be restored
     mdadm: No backup metadata on /grow_md125.back
     mdadm: Failed to find backup of critical section
     mdadm: continuing without restoring backup
     mdadm: added /dev/sdac1 to /dev/md125 as 1
     .
     .
     .
     mdadm: failed to RUN_ARRAY /dev/md125: Invalid argument

dmesg有此信息：

     md: md125 stopped.
     md/raid:md125: reshape_position too early for auto-recovery - aborting.
     md: pers->run() failed ...
     md: md125 stopped.

由于上述所有情况，我从救援 CD 启动并能够将其重塑为原来的 30 个设备并重新启动到本地安装（我确实必须从 fstab 中注释掉该阵列才能这样做）。

答案1

我想延伸上述建议。

这是非常值得设置覆盖块设备，因此您在尝试恢复文件系统时所做的任何更改都不会改变 RAID 上的任何内容，这将允许您重置所有内容并从头开始。因此，您将获得无限次尝试的机会，从而释放心理压力。

我使用 Qemu qemu-nbd、Linux nbd.ko（网络块设备驱动程序）和 qcow2 覆盖文件完成了此操作。

  1. 连接将存储覆盖的附加磁盘。加载 NBD 驱动程序。将暂存盘安装在某处：
modprobe nbd
mount /dev/sdXXN /tmp/overlay
  1. 创建 qcow2 覆盖文件：
qemu-img create -f qcow2 -b /dev/md125 -F raw /tmp/overlay/attempt1.qcow2
  1. 使用以下方法从覆盖文件创建块设备qemu-nbd：
qemu-nbd -c /dev/nbd0 /tmp/overlay/attempt1.qcow2

现在您有一个/dev/nbd0，它是您的阵列的“可写克隆”。您可以安全地写入此设备，任何更改都将写入/tmp/overlay/attempt1.qcow2。因此，例如，当您尝试@shodanshok的建议时，请将其应用于/dev/nbd0。

  1. 如果卡住了，请断开覆盖并删除覆盖文件
qemu-nbd -d /dev/nbd0
rm /tmp/overlay/attempt1.qcow2

然后重复步骤 (2) 中的所有操作。或者，您可以创建空间和设备允许的尽可能多的覆盖图/dev/nbdX（例如，我有 16 个），并并行工作。当然，它们都应该使用不同的覆盖图。如果您碰巧在某次尝试中只恢复了部分数据，而在另一次尝试中恢复了另一部分数据，那么这种方法就很有用。

当使用 XFS 文件系统的克隆时，请记住每个克隆都应该具有不同的 UUID。

当（如果）找到正确的恢复路径时，可以将其重新应用到原始设备，“不可逆地恢复文件系统”，或者您可以租用一些空间，从覆盖 NBD 转储恢复的数据，重新创建 RAID 和文件系统并将其下载回来。

我知道，这很困难而且很麻烦。这就是为什么数据恢复组织在使用 RAID 时收费很高的原因。当您亲自尝试时，您会同意这些费用并不像乍一看那么高。

我再重复一遍，30 个设备的 RAID6 很麻烦。最好有 3 个 RAID6 阵列，每个阵列有 10 个驱动器，然后使用分层 MD RAID 0 或 LVM 将它们条带化在一起。这将使事情更易于管理，并且您的重塑/检查操作不会花费数周时间才能完成。是的，您会定期进行 RAID 一致性检查（清理），至少每隔一个月一次，不是吗？

更新：评论中有一些有价值的信息，值得在这里添加。

  • 我怀疑 qemu 的东西是否会在 Synology DSM 中可用。但您可以将磁盘连接到装有 Linux 的普通 PC 并继续。或者尝试从网络或 LiveUSB 启动 Synology — 可以连接 30 个磁盘的 NAS 基本上是一台普通的 amd64 机架式计算机。–

  • @Mark 建议另一种创建覆盖的方法：

@Bob，还有其他创建覆盖的选项——我使用了 USB 拇指驱动器，步骤如下https://raid.wiki.kernel.org/index.php/Recovering_a_damaged_RAID

不错的方法，它使用 Device Mapper 框架，很可能存在于 DSM 中！而且它可能比我的方法更快。它是dmsetup使用稀疏覆盖文件创建虚拟设备的命令。但是，由于 RAID 阵列本身在您的情况下看起来很干净，而我们讨论的只是修复文件系统，因此我建议创建组装阵列（/dev/md125）的覆盖，而不是单个阵列组件的覆盖。

答案2

日志

[13297.001208] XFS (md125): Mounting V5 Filesystem
[13297.008854] XFS (md125): Log inconsistent (didn't find previous header)
[13297.008874] XFS (md125): failed to find log head
[13297.008878] XFS (md125): log mount/recovery failed: error -5
[13297.008934] XFS (md125): log mount failed

我觉得中止的重塑“打乱”了 LBA 编号，因此 XFS 找不到其意图日志。这可能意味着广泛的损坏，因此正如其他人所说的那样，就此停止并联系专业的数据恢复服务。

如果这不可能的话，我会尝试最后一次尝试，忽略 XFS 日志，mount -o ro,norecovery /dev/md125 /export/models但极不可能的情况如果它起作用，请准备好大量数据损坏。

再次强调，如果它存储了关键数据，请在采取任何行动之前联系数据恢复公司。

相关内容