主页 / server / 问题 / 443763
Accepted
Ole Tange
Asked: 2012-10-31 08:16:12 +0800 CST

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

  • 772

这类似于从 Raid6 mdadm 中掉出 3 个驱动器 - 重建？除了它不是由于电缆故障。相反，第三个驱动器在重建另一个驱动器期间掉线了。

驱动器出现故障：

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-consistency 检查。

如果可行，请检查该解决方案是否也适用于真实设备（例如 4 个 USB 记忆棒）。

software-raid

1 个回答

  1. Best Answer

    魔法似乎是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

    到最后一切都syncOK。只有在最后一次同步之后写的东西才是古怪的。

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

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

    ==

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

    ==

    到目前为止，没有用户报告丢失文件，因此它似乎有效。

    • 1

相关问题