我发现 mdadm --detail 和 mdadm --examine 的输出之间存在差异，但我不明白为什么。
此输出
mdadm --detail /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Wed Mar 14 18:20:52 2012
Raid Level : raid10
Array Size : 3662760640 (3493.08 GiB 3750.67 GB)
Used Dev Size : 1465104256 (1397.23 GiB 1500.27 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 2
Persistence : Superblock is persistent
似乎与此相矛盾。（阵列中的每个磁盘都相同）
mdadm --examine /dev/sdc2
/dev/sdc2:
Magic : a92b4efc
Version : 0.90.00
UUID : 1f54d708:60227dd6:163c2a05:89fa2e07 (local to host)
Creation Time : Wed Mar 14 18:20:52 2012
Raid Level : raid10
Used Dev Size : 1465104320 (1397.23 GiB 1500.27 GB)
Array Size : 2930208640 (2794.46 GiB 3000.53 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 2
数组就是这样创建的。
mdadm -v --create /dev/md2 \
--level=raid10 --layout=o2 --raid-devices=5 \
--chunk=64 --metadata=0.90 \
/dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2
5 个独立驱动器均有这样的分区。
Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00057754
Device Boot Start End Blocks Id System
/dev/sdc1 2048 34815 16384 83 Linux
/dev/sdc2 34816 2930243583 1465104384 fd Linux raid autodetect
背景故事
因此，我提供支持的盒子中的 SATA 控制器出现故障。故障非常严重，因此单个驱动器一次一点地从阵列中掉出来。虽然有备份，但我们并没有像我们真正需要的那样频繁地进行备份。如果可以的话，我正在尝试恢复一些数据。
我获得了额外的硬件，并且能够再次访问驱动器。驱动器看起来没问题，我可以激活并安装阵列和文件系统（使用只读模式）。我能够访问文件系统上的某些数据，并且已经将其复制，但是当我尝试复制最新数据时，我看到很多错误。
当我尝试访问最新数据时，出现如下错误，这让我认为数组大小差异可能是问题所在。
Mar 14 18:26:04 server kernel: [351588.196299] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.196309] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.196313] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.199260] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.199264] dm-7: rw=0, want=20647626304, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.202446] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.202450] dm-7: rw=0, want=19973212288, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.205516] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.205520] dm-7: rw=0, want=8009695096, limit=6442450944
答案1
您确定创建阵列的命令行吗？我的猜测是，这是一个带有热备用驱动器的“标准” 4 驱动器 raid10 阵列，这可以解释 /dev/sdc2 的结果
您能告诉我们结果吗：
cat /proc/mdstat
cat /etc/mdadm.conf
mdadm --examine /dev/sdx2 ( each drive )
这样，您也许能够猜出哪个驱动器是热备用驱动器，这样您就可以正确地重建阵列。当然，正如 3dinfluence 所述，您应该在尝试重新配置阵列之前复制数据。
编辑：另外，运行以下命令可能并不浪费时间：
smartctl -a /dev/sdx在每个驱动器上（检查输出末尾是否报告了错误），然后smartcl -t long /dev/sdx在 3 或 4 小时后再次使用 smartctl -a 检查 5 个磁盘是否真的很好。如果一个磁盘报告错误，可能是 mdadm 检测到它有故障，因此 mdadm 启用了备用驱动器（始终是猜测）
编辑 2：如果 vgs 报告：vgdisplay 显示 Alloc PE/Size 3.00 TiB，Free PE/Size 421.08 这意味着您的 PV 神秘地增长了 421G。我坚持我的观点：“神秘”增长是您的阵列配置错误。您的阵列的实际大小是 3T。您没有正确地重新组装它，因此它已损坏。为了正确地重新组装它，您需要检索原始配置以及哪个驱动器是备用驱动器。祝你好运。
答案2
如果你能用 dd 克隆驱动器，那么我会这么做。尽可能保持原始驱动器不变。
那么这完全是凭空而来，但如果我处于那种情况，我会尝试这样做。使用系统中的克隆驱动器，我会
mdadm --zero-superblock /dev/sdx#
在每个相关驱动器上使用 RAID 元数据。
然后使用该命令重新创建阵列。
mdadm -v --create /dev/md2 \
--level=raid10 --layout=o2 --raid-devices=5 \
--chunk=64 --metadata=0.90 --assume-clean \
/dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2
这应该可以解决所有 raid 级别问题。然后您可以尝试重新安装文件系统并查看剩余的内容。如果这不起作用，请重新克隆您的驱动器并尝试其他方法 :)