这类似于3驱动器掉了Raid6 mdadm – 重build？ 除非这不是由于电缆故障。 相反，第三个驱动器在重build另一个驱动器时掉线。
驱动器失败：
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是好的，也许有一些缺less最近的文件。
对RAID中的磁盘进行备份需要24小时，所以我宁愿第一次使用该解决scheme。
因此我build立了一个testing场景：
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一致性检查。
当这个工作，检查解决scheme也适用于真正的设备（如4个USB记忆棒）。
神奇似乎是mdadm -A --force ，然后只给予那些已知好的设备+最后一个失败的设备。 对于testing场景将是：
mdadm -A --force /dev/md$PRE /dev/loop${PRE}[125]
这启动RAID设备。 xfs_check您安装磁盘以重放日志：
mount /dev/md$PRE /mnt/disk2
此时不要使用目录：在testing场景中，我至less有一次xfs抱怨和崩溃。 所以与其：
umount /mnt/disk2
接着：
xfs_check /dev/md$PRE
这在50TB的文件系统上花了20分钟。 奇怪的是，大部分时间都是CPU时间，而不是等待磁盘I / O。 它使用了100 GB RAM的顺序。
现在文件系统再次可用：
mount /dev/md$PRE /mnt/disk2
到最后一个sync所有东西都可以。 只有在上次同步之后写入的东西是flakey。
添加一些备件并重build。
当明天复制现有的磁盘时，我会testing以上。 如果有效，那么以上是答案。 否则，将开始复制原始集合，并欢迎新的想法（但请在testing场景中testing它们）。
==
现在添加备件并重新开始。 每第1000个文件被复制到文件系统上的目录，这不会导致日志中的问题。 所以看起来文件系统是好的。 用户是否遗漏了一些文件还有待观察。
==
目前没有用户报告丢失的文件，所以它似乎工作。