Невозможно смонтировать файловую систему XFS из массива Linux RAID6 («Несовместимый журнал»)

Плакат в первый раз - мои извинения, если я не понимаю этикет правильно.

У меня есть массив RAID6 размером ~ 200 ТБ с 30 дисками, и я не могу его смонтировать - я просто получаю сообщение:

смонтировать /dev/md125 /экспорт/модели
mount:/dev/md125: невозможно прочитать суперблок

Если я побегу мдадм --деталь на нем он отображается как чистый:

/dev/md125:
           Версия : 1.2
     Время создания: ср 13 сентября 15:09:40 2017
        Уровень рейда: рейд 6.
        Размер массива: 218789036032 (203,76 ТиБ 224,04 ТБ)
     Используемый размер разработки: 7813894144 (7,28 ТиБ, 8,00 ТБ)
      Рейдовые устройства: 30
     Всего устройств: 30
       Постоянство: суперблок постоянен

     Растровое изображение намерения: внутреннее

       Время обновления: пятница, 20 мая, 23:54:52 2022 г.
             Состояние: чистое
    Активные устройства: 30
   Рабочие устройства: 30
    Неудачные устройства: 0
     Запасные устройства : 0

            Макет: левосимметричный
        Размер блока: 512 КБ

Политика согласованности: растровое изображение

              Имя: localhost.localdomain:SW-RAID6
              UUID: f9b65f55:5f257add:1140ccc0:46ca6c19
            События : 1152436

    Номер Основной Младший RaidDevice State
       0 8 1 0 активная синхронизация /dev/sda1
       1 65 161 1 активная синхронизация /dev/sdaa1
       2 65 177 2 активная синхронизация /dev/sdab1
       3 65 193 3 активная синхронизация /dev/sdac1
       4 65 209 4 активная синхронизация /dev/sdad1
       5 8 17 5 активная синхронизация /dev/sdb1
       6 8 33 6 активная синхронизация /dev/sdc1
       7 8 49 7 активная синхронизация /dev/sdd1
       8 8 65 8 активная синхронизация /dev/sde1
       9 8 81 9 активная синхронизация /dev/sdf1
      10 8 97 10 активная синхронизация /dev/sdg1
      11 8 113 11 активная синхронизация /dev/sdh1
      12 8 129 12 активная синхронизация /dev/sdi1
      13 8 145 13 активная синхронизация /dev/sdj1
      14 8 161 14 активная синхронизация /dev/sdk1
      15 8 177 15 активная синхронизация /dev/sdl1
      16 8 193 16 активная синхронизация /dev/sdm1
      17 8 209 17 активная синхронизация /dev/sdn1
      18 8 225 18 активная синхронизация /dev/sdo1
      19 8 241 19 активная синхронизация /dev/sdp1
      20 65 1 20 активная синхронизация /dev/sdq1
      21 65 17 21 активная синхронизация /dev/sdr1
      22 65 33 22 активная синхронизация /dev/sds1
      23 65 49 23 активная синхронизация /dev/sdt1
      24 65 65 24 активная синхронизация /dev/sdu1
      25 65 81 25 активная синхронизация /dev/sdv1
      26 65 97 26 активная синхронизация /dev/sdw1
      27 65 113 27 активная синхронизация /dev/sdx1
      28 65 129 28 активная синхронизация /dev/sdy1
      29 65 145 29 активная синхронизация /dev/sdz1

кошка /прок/статистика показывает:

[root@knox ~]# кошка /proc/mdstat
Личности: [raid1] [raid6] [raid5] [raid4]
md125 : активный raid6 sdo1[18] sdh1[11] sdad1[4] sdd1[7] sdb1[5] sdi1[12] sdt1[23] sdr1[21] sdp1[19] sdx1[27] sdg1[10] sdn1[ 17] sdm1[16] sdab1[2] sdu1[24] sdl1[15] sde1[8] sdf1[9] sdw1[26] sdc1[6] sdq1[20] sdy1[28] sds1[22] sdv1[25] sdac1[3] sdz1[29] sdaa1[1] sda1[0] sdj1[13] sdk1[14]
      218789036032 блоков super 1.2 level 6, чанк 512k, алгоритм 2 [30/30] [UUUUUUUUUUUUUUUUUUUUUUUUUUUUUU]
      растровое изображение: 0/59 страниц [0 КБ], фрагмент 65536 КБ

md126 : активный рейд1 sdae3[0] sdaf2[1]
      976832 блока супер 1.0 [2/2] [UU]
      растровое изображение: 0/1 страницы [0 КБ], фрагмент 65536 КБ

md127 : активный рейд1 sdaf1[1] sdae1[0]
      100554752 блока супер 1.2 [2/2] [UU]
      растровое изображение: 1/1 страницы [4 КБ], фрагмент 65536 КБ

неиспользуемые устройства: <нет>

Исследовать на отдельных устройствах также отображается как исправный (я не включил результаты для них всех, потому что это заняло бы слишком много места, но они все такие же, как этот):

/dev/sda1:
          Магия: a92b4efc
        Версия : 1.2
    Карта функций: 0x1
     UUID массива: f9b65f55:5f257add:1140ccc0:46ca6c19
           Имя: localhost.localdomain:SW-RAID6
  Время создания: ср 13 сентября 15:09:40 2017
     Уровень рейда: рейд 6.
   Рейдовые устройства: 30

 Доступный размер разработчика: 15627788288 секторов (7,28 ТиБ, 8,00 ТБ)
     Размер массива: 218789036032 КиБ (203,76 ТиБ 224,04 ТБ)
    Смещение данных: 262144 сектора
   Супер смещение: 8 секторов
   Неиспользованное пространство: до = 262056 секторов, после = 0 секторов
          Состояние: чистое
    UUID устройства: 917e739e:36fa7cf6:c618d73c:43fb7dec

Внутреннее растровое изображение: 8 секторов из суперблока
    Время обновления: пятница, 20 мая, 23:54:52 2022 г.
  Журнал плохих блоков: 512 записей доступны по смещению 72 сектора
       Контрольная сумма: 2b5e9556 - правильно
         События : 1152436

         Макет: левосимметричный
     Размер блока: 512 КБ

   Роль устройства: активное устройство 0
   Состояние массива: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ('A' == активно, '.' == отсутствует, 'R' == замена)

Соответствующие записи в dmesg показывают:

[13297.001208] XFS (md125): монтирование файловой системы V5
[13297.008854] XFS (md125): журнал несогласован (предыдущий заголовок не найден)
[13297.008874] XFS (md125): не удалось найти заголовок журнала
[13297.008878] XFS (md125): ошибка монтирования/восстановления журнала: ошибка -5
[13297.008934] XFS (md125): сбой монтирования журнала

Предыстория этого довольно длинная и сложная, но короткая версия заключается в том, что я пытался увеличить массив с добавлением дополнительного диска, и операция была прервана. В конце концов я восстановил массив, изменив его форму до исходных 30 дисков (что заняло целых две недели!), Но теперь он не хочет монтироваться.

К сожалению, это не резервное копирование (я имею в виду, где вы делаете резервные копии 200 ТБ?!?!). Здесь не должно было храниться ничего ценного, но люди, каковы они есть, там хранились некоторые важные вещи.

я посмотрел на xfs_repair но я не уверен, следует ли запускать его на массиве RAID (md125) или на отдельных устройствах sd*.

Спасибо

Обновление (история всего этого):

Устройство представляет собой сервер SuperMicro под управлением CentOS 7 (3.10.0-1160.11.1.e17.x86_64) с версией 4.1 — 01.10.2018 mdadm с 30 дисками по 8 ТБ в конфигурации RAID6. Он также имеет загрузку и root на 2 массивах RAID1 — массив RAID6 предназначен исключительно для данных. На нем заканчивалось место, поэтому мы решили добавить в массив больше дисков (всего он может содержать 45 дисков).

Поскольку исходный диск в массиве был 4kN, а поставляемые устройства были 512e, необходимо было переформатировать их с помощью sg_format для их преобразования (процедура, поддерживаемая Western Digital). Я начал с одного диска в качестве теста. К сожалению, процесс был прерван на полпути, поэтому я перезапустил его и завершил нормально, вроде как… он преобразовал диск в 4096 КБ, но выдал одну или две ошибки ввода-вывода, но они не казались слишком важными, и я полагал, что если есть проблема, она обнаружится через следующие пару шагов. С тех пор я обнаружил журнал dmesg, который показал, что ошибок ввода-вывода значительно больше, чем я думал.

В любом случае, поскольку sg_format, казалось, завершился нормально, я перешел к следующему этапу, который должен был разбить диск с помощью следующих команд.

     parted -оптимальный /dev/sd<x>
     (разделенный) mklabel msdos
     (parted) mkpart primary 2048s 100% (нужно проверить правильность запуска)
     (parted) align-check optimal 1 (проверить выравнивание раздела 1)
     (parted) установить 1 рейд (установить ФЛАГ на RAID)
     (разделенный) печать

Затем я добавил новый диск в массив:

     mdadm --добавить /dev/md125 /dev/sd<x>

И завершилось без проблем.

Затем я приступил к увеличению массива:

     mdadm --grow --raid-devices=31 --backup-file=/grow_md125.bak /dev/md125

Я отслеживал это с помощью cat /proc/mdstat, и он показал, что он меняет форму, но скорость составляет 0 КБ/сек, а изменение формы не происходит с 0%.

Примерно через 12 часов, когда изменение формы не прогрессировало с 0%, я рассмотрел способы его прерывания, такие как mdadm --stop /dev/md125, что не сработало, поэтому я перезагрузил сервер.

Сервер перешел в аварийный режим.

Я смог войти в систему как root OK, но массив RAID6 застрял в состоянии изменения формы.

затем я попытался mdadm --assemble --update=revert-reshape --backup-file=/grow_md125.bak --verbose --uuid= f9b65f55:5f257add:1140ccc0:46ca6c19 /dev/md125 и это произвело:

     mdadm: суперблок не найден в /dev/sde (ожидается волшебство a92b4efc, получено <различные числа>
     mdadm: нет суперблока RAID в /dev/sde
     .
     .
     mdadm: /dev/sde1 определяется как член /dev/md125, слот 6
     .
     .
     mdadm: /dev/md125 имеет активное изменение формы — проверка необходимости восстановления критического раздела
     mdadm: нет резервных метаданных в /grow_md125.back
     mdadm: не удалось найти резервную копию критической секции
     mdadm: Не удалось восстановить критическую секцию для изменения формы, извините.

Я пробовал различные варианты этого, включая mdadm --assemble --invalid-backup --force все безрезультатно.

В этот момент я также удалил подозрительный диск, но это ничего не изменило.

Но самое близкое, что я подошел к исправлению, это запуск mdadm /dev/md125 --assemble --invalid-backup --backup-file=/grow_md125.bak --verbose /dev/sdc1 /dev/sdd1 ....... /dev/sdaf1 и это производит:

     mdadm: /dev/sdaf1 идентифицируется как член /dev/md125, слот 4.
     mdadm: /dev/md125 имеет активное изменение формы — проверка необходимости восстановления критического раздела
     mdadm: нет резервных метаданных в /grow_md125.back
     mdadm: не удалось найти резервную копию критической секции
     mdadm: продолжение без восстановления резервной копии
     mdadm: добавлен /dev/sdac1 в /dev/md125 как 1
     .
     .
     .
     mdadm: не удалось выполнить RUN_ARRAY /dev/md125: неверный аргумент

dmesg имеет эту информацию:

     md: md125 остановлен.
     md/raid:md125: reshape_position слишком рано для автоматического восстановления - прерывание.
     md: pers->run() не удалось...
     md: md125 остановлен.

После всего вышеперечисленного я загрузился с загрузочного компакт-диска и смог изменить его форму до исходных 30 устройств и загрузиться обратно в исходную установку (для этого мне пришлось выделить этот массив из fstab).

Я хочу расширить предложения выше.

это чрезвычайно ценный настройка блочного устройства оверлея, поэтому любые изменения в файловой системе, которые вы будете делать при попытке восстановить его, ничего не изменят на RAID, и это позволит вам сбросить все и начать с самого начала. Таким образом, вам будет предоставлено бесконечное количество попыток, что позволит снять психологическое давление.

Я сделал это с Qemu qemu-nbd, линукс nbd.ko (драйвер сетевого блочного устройства) и файл наложения qcow2.

1. Подключите дополнительный диск, на котором будет храниться оверлей. Загрузите драйвер NBD. Смонтируйте рабочий диск куда-нибудь:

modprobe nbd
смонтировать /dev/sdXXN /tmp/оверлей

2. Создайте файл оверлея qcow2:

qemu-img create -f qcow2 -b /dev/md125 -F raw /tmp/overlay/attempt1.qcow2

3. Создайте блочное устройство из файла оверлея, используя qemu-nbd:

qemu-nbd -c /dev/nbd0 /tmp/overlay/attempt1.qcow2

Теперь у вас есть /dev/nbd0 который является "перезаписываемым клоном" вашего массива. Вы можете смело писать на это устройство, любые изменения будут записаны на /tmp/оверлей/попытка1.qcow2. Так, например, когда вы пытаетесь следовать совету @shodanshok, применяйте его к /dev/nbd0.

4. Если застряли, отключите оверлей и удалите файл оверлея

qemu-nbd -d /dev/nbd0
РМ /tmp/overlay/attempt1.qcow2

Затем повторите все, начиная с шага (2). Кроме того, вы можете создать столько оверлеев, сколько есть места и /dev/nbdX устройства разрешают (у меня их, например, 16) и работают параллельно. Разумеется, все они должны использовать разные накладываемые изображения. Это полезно, если вы восстанавливаете только частичные данные при одной попытке и другую часть данных при другой попытке.

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

Когда (если) правильный путь восстановления найден, его можно повторно применить к необработанному устройству, «необратимо восстановив файловую систему», или вы можете арендовать некоторое пространство, сбросить туда восстановленные данные из оверлейных NBD, воссоздать RAID и файловую систему и загрузить его. назад.

Я знаю, это сложно и хлопотно. Вот почему организации по восстановлению данных берут большие деньги за работу с RAID. Когда вы попробуете это сами, вы согласитесь, что эти счета не так завышены, как может показаться на первый взгляд.

И еще раз повторяю, RAID6 из 30 устройств — это боль. Лучше иметь, например. 3 массива RAID6 по 10 дисков в каждом, затем чередуйте их вместе с помощью многоуровневого MD RAID 0 или LVM. Это сделает вещи более управляемыми, и ваши операции по изменению/проверке не займут недели. Да, вы регулярно выполняете проверки согласованности RAID (очистку), по крайней мере, раз в два месяца, не так ли?

Обновлять: В комментариях есть ценная информация, которую стоит добавить сюда.

• Я сомневаюсь, что материалы qemu будут доступны в Synology DSM. Но вы можете подключить диски к обычному ПК с Linux и продолжить. Или попробуйте загрузить Synology из сети или с LiveUSB — NAS, к которому можно подключить 30 дисков, — это, по сути, обычный компьютер amd64, устанавливаемый в стойку. ✓

• @Mark предлагает другой способ создания наложения:

@ Боб, есть и другие варианты создания наложения — я использовал флэш-накопитель USB и шаги, описанные в https://raid.wiki.kernel.org/index.php/Recovering_a_damaged_RAID

Хороший способ, использующий фреймворк Device Mapper, вероятно, присутствует в DSM! Также это, вероятно, быстрее, чем мой подход. это dmsetup Команда, которая создает виртуальное устройство с разреженным файлом оверлея. Однако, поскольку сам RAID-массив в вашем случае выглядит чистым, а речь идет только о исправлении файловой системы, предлагаю создать оверлей собранного массива (/dev/md125), а не отдельных компонентов массива.

Журналы

[13297.001208] XFS (md125): монтирование файловой системы V5
[13297.008854] XFS (md125): журнал несогласован (предыдущий заголовок не найден)
[13297.008874] XFS (md125): не удалось найти заголовок журнала
[13297.008878] XFS (md125): ошибка монтирования/восстановления журнала: ошибка -5
[13297.008934] XFS (md125): сбой монтирования журнала

заставьте меня думать, что прерванное изменение формы "перемешало" номер LBA, так что XFS не находит свой журнал намерений.Это, вероятно, означает широкую коррупцию, поэтому, как уже было сказано другими, остановитесь здесь и обратитесь в профессиональную службу восстановления данных.

Если это невозможно, я бы попробовал последнюю попытку, проигнорировав журнал XFS с чем-то вроде mount -o ro, norecovery /dev/md125 /export/models но в очень маловероятный случай если это сработает, будьте готовы к обширному повреждению данных.

Опять же, если на нем хранятся важные данные, обратитесь в фирму по восстановлению данных, прежде чем что-либо делать.