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