无法从Linux RAID6数组挂载XFS文件系统(“日志不一致”)
第一次招贴画-如果我没有正确的礼仪，我很抱歉。
我有一个包含30个磁盘的~200 to 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/sdz1cat /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个磁盘上(这花了整整两个星期！)但现在它不想上山了。
不幸的是，它没有备份(我的意思是fdo您在哪里备份200 to？！！)。没有任何有价值的东西应该储存在这里，但是，人类，他们是什么，一些有价值的东西被储存在那里。
我看过xfs_repair，但我不确定是在RAID数组(md125)上还是在单独的sd*设备上运行它。
谢谢
更新(这一切背后的历史)：
该设备是运行SuperMicro 7 (3.10.0-1160.11.1.e17.x86_64)的CentOS服务器，其4.1-2018-10-01版本的mdadm在RAID6配置中具有30x8TB磁盘。它还在两个RAID1数组上启动和根目录-- RAID6数组仅用于数据。它正在耗尽空间，所以我们决定向数组中添加更多的驱动器(它总共可以容纳45个驱动器)。
由于阵列中的原始磁盘为4kN驱动器，所提供的设备为512 e，因此有必要用sg_format重新格式化它们以转换它们(西部数据支持的过程)。作为测试，我从一个磁盘开始。不幸的是，这个过程被中断了一部分，所以我重新启动了它，并完成了OK，有点-它确实将磁盘转换为4096 K，但是它确实抛出了一两个I/O错误，但它们看起来并不太值得关注，我想，如果有问题，它会在接下来的几个步骤中出现。此后，我发现了dmesg日志，这表明I/O错误比我想象的要多得多。
无论如何，由于sg_format似乎完成了OK，所以我进入了下一个阶段，即使用以下命令对磁盘进行分区
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/‘t 125，它没有工作，所以我最终重新启动了服务器。
服务器以紧急模式出现。
我能够以root OK的身份登录，但RAID6数组ws仍停留在重塑状态。
然后我尝试了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 argumentdmesg有以下信息：
md: md125 stopped.
md/raid:md125: reshape_position too early for auto-recovery - aborting.
md: pers->run() failed ...
md: md125 stopped.由于以上所述，我从一张救援CD中启动，并能够将其重新定位到最初的30个设备，并已重新启动到本机安装中(为此，我必须注意到这个数组是从fstab开始的)。
回答 2
Server Fault用户
发布于 2022-05-22 08:25:24
我想提出以上建议。
设置覆盖块设备是非常值得的，因此对文件系统所做的任何更改都不会改变RAID上的任何内容，这将使您可以从一开始就重置所有内容。因此，你将得到无限的尝试，从而释放心理压力。
我使用的是Qemu的qemu-nbd、Linux nbd.ko (网络块设备驱动程序)和qcow2覆盖文件。
- 连接将存储覆盖层的其他磁盘。加载NBD驱动程序。将您的划痕磁盘安装在某个地方：
modprobe nbd
mount /dev/sdXXN /tmp/overlay- 创建一个qcow2覆盖文件：
qemu-img create -f qcow2 -b /dev/md125 -F raw /tmp/overlay/attempt1.qcow2- 使用
qemu-nbd创建一个覆盖文件外的块设备：
qemu-nbd -c /dev/nbd0 /tmp/overlay/attempt1.qcow2现在您有了一个/dev/nbd0，它是数组的“可写克隆”。您可以安全地写入此设备，任何更改都将写入/tmp/overlay/attempt1.qcow2。因此，例如，当您尝试@shodanshok的建议时，将其应用于/dev/nbd0。
- 如果卡住，请断开覆盖并移除覆盖文件。
qemu-nbd -d /dev/nbd0
rm /tmp/overlay/attempt1.qcow2然后重复步骤(2)中的所有内容。或者，您可以在空间和/dev/nbdX设备允许的范围内创建尽可能多的覆盖(例如，我有16个)并并行工作。当然，它们都应该使用不同的叠加图像。如果在某些尝试中只恢复部分数据，而在其他尝试中仅恢复数据的另一部分，则此操作非常有用。
当使用XFS文件系统的克隆时，请记住它们每个都应该有不同的UUID。
当(如果)找到正确的恢复路径时，可以将其重新应用于原始设备，“不可逆转地恢复文件系统”，或者您可以租用一些空间，从overlay NBD那里转储恢复的数据，重新创建RAID和文件系统并将其下载回来。
我知道，这又难又麻烦。这就是为什么数据恢复组织在进行突袭时收费很高的原因。当你自己尝试的时候，你会同意这些钞票并不像乍一看上去那么膨胀。
我再说一遍，30个设备的RAID6是痛苦的。最好有3个RAID6阵列，每个驱动器10个，然后使用分层MD 0或LVM将它们分割在一起。这将使事情变得更容易管理，并且您的整形/检查操作将不需要几个星期就能完成。是的，你定期进行RAID一致性检查(清洗)，至少每隔一个月进行一次，不是吗？
更新:评论中有一些有价值的信息，值得在这里添加。
- 我怀疑qemu的东西将在综合征DSM中提供。但是你可以用Linux将磁盘连接到普通PC上，然后继续工作。或者尝试从网络或LiveUSB引导语法- NAS，它可以连接30个磁盘，基本上是一个普通的amd64机架挂载计算机。-
- @Mark建议另一种创建覆盖的方法：
@Bob，还有其他创建覆盖的选项--我使用了USB拇指驱动器和https://raid.wiki.kernel.org/index.php/Recovering_一个_受损_RAID的步骤
不错的方法，它使用设备Mapper框架，可能会出现在DSM！而且，它可能比我的方法更快。是dmsetup命令创建了具有稀疏覆盖文件的虚拟设备。但是，由于RAID数组本身在您的示例中是干净的，而且我们所讨论的只是修复文件系统，所以我建议创建组装数组(/dev/md125)的覆盖，而不是单个数组组件的覆盖。
Server Fault用户
发布于 2022-05-22 07:59:53
原木
[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找不到它的意图日志。这可能意味着广泛的损坏，因此，正如其他人已经说过的，请停止这里，并联系专业的数据恢复服务。
如果这是不可能的，我将尝试最后一次尝试，使用mount -o ro,norecovery /dev/md125 /export/models之类的东西忽略XFS日志，但是在非常不可能的情况下，如果它起作用的话，就要准备好大范围的数据损坏。
同样，如果它存储了关键数据，在做任何事情之前，请与数据恢复公司联系。
https://serverfault.com/questions/1101514
复制相似问题
腾讯云开发者
