☰

Linux 软件 RAID6：3 个驱动器离线 - 如何强制在线？

tag-icon • tag-icon software-raid mdadm raid6
Linux 软件 RAID6：3 个驱动器离线 - 如何强制在线？

这类似于3 个驱动器从 Raid6 mdadm 中掉出来了——重建吗？但这并不是由于电缆故障造成的。而是由于重建另一个驱动器时，第三个驱动器离线了。

驱动器发生故障：

kernel: end_request: I/O error, dev sdc, sector 293732432
kernel: md/raid:md0: read error not correctable (sector 293734224 on sdc).

重启后，这两个扇区和它们周围的扇区都正常。这让我相信错误是间歇性的，因此设备只是花了太长时间来纠正扇区的错误并重新映射它。

我预计 RAID 发生故障后不会写入任何数据。因此，我希望如果我可以将最后一个发生故障的设备启动到在线状态，那么 RAID 和 xfs_filesystem 就没问题了，也许会丢失一些最近的文件。

备份 RAID 中的磁盘需要 24 小时，因此我希望该解决方案第一次就能成功。

因此我设置了一个测试场景：

export PRE=3

parallel dd if=/dev/zero  of=/tmp/raid${PRE}{} bs=1k count=1000k ::: 1  2  3  4  5
parallel mknod /dev/loop${PRE}{} b 7 ${PRE}{} \; losetup /dev/loop${PRE}{} /tmp/raid${PRE}{} ::: 1  2  3  4  5
mdadm --create /dev/md$PRE -c 4096 --level=6 --raid-devices=5  /dev/loop${PRE}[12345]
cat /proc/mdstat
mkfs.xfs -f /dev/md$PRE
mkdir -p /mnt/disk2
umount -l /mnt/disk2
mount /dev/md$PRE /mnt/disk2
seq 1000 | parallel -j1 mkdir -p /mnt/disk2/{}\;cp /bin/* /mnt/disk2/{}\;sleep 0.5 &
mdadm --fail /dev/md$PRE /dev/loop${PRE}3 /dev/loop${PRE}4
cat /proc/mdstat

# Assume reboot so no process is using the dir
kill %1; sync &
kill %1; sync &

# Force fail one too many
mdadm --fail /dev/md$PRE /dev/loop${PRE}1
parallel --tag -k mdadm -E ::: /dev/loop${PRE}? | grep Upda
# loop 2,5 are newest. loop1 almost newest => force add loop1

下一步是添加回 loop1 - 这就是我遇到的问题。

之后进行 xfs 一致性检查。

当其起作用时，检查该解决方案是否也适用于真实设备（例如 4 个 USB 记忆棒）。

答案1

魔法似乎是mdadm -A --force，然后只给出已知良好的设备 + 最后一个发生故障的设备。对于测试场景，这将是：

mdadm -A --force /dev/md$PRE /dev/loop${PRE}[125]

这将启动 RAID 设备。xfs_check告诉您安装磁盘以重播日志：

mount /dev/md$PRE /mnt/disk2

此时不是使用目录：在测试场景中，我至少遇到过一次 xfs 抱怨和崩溃的情况。因此，改为：

umount /mnt/disk2

进而：

xfs_check /dev/md$PRE

这在 50 TB 文件系统上花费了 20 分钟。奇怪的是，大部分时间都是 CPU 时间，而不是等待磁盘 I/O。它使用了大约 100 GB 的 RAM。

现在文件系统可以再次使用了：

mount /dev/md$PRE /mnt/disk2

到最后为止一切sync都正常。只有在最后一次同步之后写入的内容才有点问题。

添加一些备件并进行重建。

明天现有磁盘复制完成后，我将测试上述内容。如果有效，则上述内容就是答案。否则将开始对原始磁盘组进行新的复制，欢迎提出新想法（但请在测试场景中进行测试）。

==

现在已添加备用文件并开始重建。每 1000 个文件都会复制到文件系统上的一个目录中，这不会在日志中引起问题。因此看来文件系统没有问题。用户是否遗漏了一些文件还有待观察。

==

到目前为止还没有用户报告文件丢失，所以它似乎是有效的。

相关内容