Это похоже на Вывалилось 3 диска из 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.
Когда это сработает, убедитесь, что решение также работает на реальных устройствах (например, 4 USB-накопителях).
Магия кажется 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
Это заняло 20 минут в файловой системе 50 ТБ. Как ни странно, большую часть времени занимало процессорное время, а не ожидание ввода-вывода с диска. Он использовал порядка 100 ГБ ОЗУ.
Теперь файловая система снова может использоваться:
mount /dev/md$PRE /mnt/disk2
Все до последнего sync
в порядке. Неаккуратным является только то, что написано после последней синхронизации.
Добавьте запасные части и проведите восстановление.
Когда завтра закончится копирование существующих дисков, я протестирую вышесказанное. Если это сработает, то это ответ. В противном случае будет начато новое копирование исходного набора, и приветствуются новые идеи (но, пожалуйста, проверьте их на тестовом сценарии).
==
Запасные части теперь добавлены и начато восстановление. Каждый 1000-й файл был скопирован в каталог файловой системы, и это не вызвало проблем в журналах. Итак, похоже, с файловой системой все в порядке. Еще неизвестно, пропустят ли пользователи какие-то файлы.
==
Пока ни один пользователь не сообщил о пропаже файлов, так что, похоже, это работает.