Прошу помочь.
Есть у меня на домашнем сервере софтовый рэйд 5 (mdadm) из 4-х винтов по 3ТБ каждый и XFS на весь рэйд. В основном файлопомойка. Служил без проблем. На днях один из винтов умер. Мне на это пришло уведомление, но сами данные были доступны и в общем все работало. Оно и понятно, что так и должно было быть, ведь это raid5. На выходных, т.е. сегодня, я решил что надо посмотреть какой именно винт сдох и не нашел ничего умнее, чем отключив демона mdadm вырубить сервер и попробовать физически отключать по одному винты, запускать потом и смотреть какие sdX «исчезли» (монитор к нему не подключен, все делал через ssh). Думаю логика понятна. Но в процессе, как я понял, выпендрился BIOS - порядок дисков поменялся и когда я вернул как было, то raid показывался как неактивный с 3 винтами с меткой (S) у каждого.
В общем после гугления я сделал так:
mdadm --stop /dev/md0
mdadm --assemble --scan -v
После такого raid вроде ожил. Но после перезагрузки системы снова был неактивным. Я пробовал заменять в /etc/mdadm.conf на выхлоп mdadm --examine --scan, но с ним почему-то не определялось в /dev/md0. В общем в итоге со старым /etc/mdadm.conf оно завелось и решил, что проблема решена, надо только замонтировать разделы. Тут я вспомнил, что все экперименты по восстановлению рейда делал не закоментировав монтирование в /etc/fstab, но по идее это не должно было приводить к проблемам, ведь все это время монтирование не должно было проходить. Возможно я ошибался. Когда я попробовал замонтировать вручную, то получил такое:
# mount /dev/md0 /files
mount: mount /dev/md0 on /files failed: Structure needs cleaning
Гугление оптимизма не добавило. Вот что выдал xfs_repair /dev/md0:
Phase 1 - find and verify superblock...
- reporting progress in intervals of 15 minutes
Phase 2 - using internal log
- zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair. If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
Я боюсь использовать -L. Я пытался нагуглить что именно в данном случае означает очистка журнала. Если пропадут последние изменения допустим за несколько часов, то пофиг. Терять данные очень не хочется.
Кстати монтирование read only с norecovery тоже не вышло - пишет туже ошибку.
Винт на замену еще не купил, но судя по симптомам это может не помочь.
Приведу /proc/mdstat на момент сбоя, но когда все работало
Personalities : [raid6] [raid5] [raid4] [raid0] [raid1] [raid10] [linear] [multipath]
md0 : active raid5 sdc1[0](F) sdb1[4] sde1[3] sda1[1]
8790792192 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [_UUU]
unused devices: <none>
Personalities : [raid6] [raid5] [raid4] [raid0] [raid1] [raid10] [linear] [multipath]
md0 : active raid5 sdb1[0] sdd1[3] sda1[1]
8790792192 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
unused devices: <none>
Еще от mdadm на текущий момент:
# mdadm --examine --scan
ARRAY /dev/md0 UUID=45944250:b5a10965:72b3103c:136c2f80
ARRAY /dev/md/data metadata=1.2 UUID=0b86cf4c:34ccaddd:0a50085a:384810a3 name=dark-river:data
# mdadm --detail --scan
ARRAY /dev/md0 metadata=1.2 name=dark-river:data UUID=0b86cf4c:34ccaddd:0a50085a:384810a3
ARRAY /dev/md0 metadata=1.2 name=dark-river:data UUID=0b86cf4c:34ccaddd:0a50085a:384810a3
Меня здесь смущает, что у mdadm --examine --scan два ARRAY с разными UUID и если эти две строки скопировать в /etc/mdadm.conf заместо той, что выше, то /dev/md0 нет, а только md127 (точно номер не помню) как автоматически определенный и в режиме только на чтение.
А так mdadm рапортует, что у него все отлично, ну кроме того, что одного устройства не хватает (DegradedArray). Могу показать другие выхлопы, просто и так очень много текста вышло. Честно говоря не понимаю почему такое произошло.
