Программное обеспечение 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-й файл был скопирован в каталог в файловой системе, и это не вызывало проблем в журналах. Так что, похоже, файловая система в порядке. Еще неизвестно, пропустят ли пользователи какие-то файлы.

==

Пока что ни один пользователь не сообщил о пропущенных файлах, поэтому, похоже, он работает.

Другие вопросы по тегам