Назад | Перейти на главную страницу

Программный RAID6 для Linux: 3 диска в автономном режиме - как принудительно подключиться к сети?

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

==

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