Linux (FC14/i386) raid1 не поврежден после горячей установки fs? Как починить?

Моя более старая установка (FC11) достигла EOL, и я попытался переустановить FC14 в его корневой файловой системе RAID1.

У меня сейчас есть подозрения, что сейчас после установки ФС не совершил рейд полностью. Вопрос в том, верно ли это подозрение, и если да, то как это исправить.

[root@atlas dev]# cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sda[0]
  732571648 blocks super external:/md0/0 [2/1] [U_]

md0 : inactive sdb[1](S) sda[0](S)
  4514 blocks super external:imsm

unused devices: <none>
[root@atlas dev]#

Кажется, md127 является некоторым дочерним контейнером md0, но в качестве явного устройства указывается sda[0], а не sdb. Я предполагаю, что я убегаю от sda, читая это, и sdb больше не существует.

Проблема в том, что с тех пор ФС видела довольно много действий, поэтому нельзя считать, что оба диска синхронизированы. SDB, вероятно, должен быть восстановлен. Хотя у меня есть полная резервная копия, поэтому я готов пойти на просчитанный риск.

Обратите внимание, что файловая система является корневым устройством. (однопользовательский режим?)

Любые объяснения, как читать вывод mdstat, также приветствуются. Я предполагаю, что мне нужно как-то добавить SDB из контейнера md0 в md127.

Выдержка из ядра:

          dracut: Starting plymouth daemon
          dracut: rd_NO_DM: removing DM RAID activation
          pata_marvell 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
          pata_marvell 0000:03:00.0: setting latency timer to 64
          scsi6 : pata_marvell
          scsi7 : pata_marvell
          ata7: PATA max UDMA/100 cmd 0xcc00 ctl 0xc880 bmdma 0xc400 irq 16
          ata8: PATA max UDMA/133 cmd 0xc800 ctl 0xc480 bmdma 0xc408 irq 16
          dracut: Autoassembling MD Raid
          md: md0 stopped.
          md: bind<sda>
          md: bind<sdb>
          dracut: mdadm: Container /dev/md0 has been assembled with 2 drives
          md: md127 stopped.
          md: bind<sda>
          md: raid1 personality registered for level 1
          md/raid1:md127: active with 1 out of 2 mirrors
          md127: detected capacity change from 0 to 750153367552
           md127: p1 p2
          md: md127 switched to read-write mode.

вывод --detail --scan:

 ARRAY /dev/md0 metadata=imsm UUID=e14582dd:1863c14a:fb0d98f0:5490080b
 ARRAY /dev/md127 container=/dev/md0 member=0 UUID=c0cf0b37:bc944eec:ac93d30e:ee2f423e

/etc/mdadm.conf:

 # mdadm.conf written out by anaconda
 MAILADDR root
 AUTO +imsm +1.x -all
 ARRAY /dev/md0 UUID=e14582dd:1863c14a:fb0d98f0:5490080b
 ARRAY /dev/md127 UUID=c0cf0b37:bc944eec:ac93d30e:ee2f423e

Обновить:

После ожидания лучшей части дня я укусил пулю, проверил свои резервные копии, загрузился в однопользовательский режим, и там я мог просто mdadm --manage /dev/md127 --add /dev/sdb

Восстановление заняло около 3 часов (неоплаченных сверхурочных). Кажется, все работает и выглядит нетронутым.

Я также помню, что я вмешивался в fakeraid, прежде чем решил перейти на программный RAID, хотя и на других дисках. Может быть, md0 - это то, что осталось от плохо восстановленного / etc, а затем билось, пока не заработало. Следующая переустановка это взорвала мне в лицо, хотя. Эксперимент, чтобы заставить это работать, вероятно, зарезервировал некоторую информацию для этого.

Страшно то, что оба массива теперь содержат одни и те же диски, и что md0 кратко включен во время загрузки. Я получаю предупреждения, которые, кажется, сигнализируют о том, что md127 является потомком md0, что делает удаление немного пугающим. Но я выкопаю загрузочный диск и на следующий день покажу время для системного администрирования. (после создания инкрементной полной резервной копии вчера)

У md127 есть два раздела (большой корень + своп), оба смонтированы. md0 не активен (и я не смею активировать его, поскольку он разделяет диски), поэтому я не знаю, какие у него разделы.

Поскольку md127 теперь работает (2/2 UU), теперь необходимо выяснить, можно ли безопасно удалить md0 (потомок md127 для md0?) И, если да, то как избежать проблем во время будущих установок.

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

1 ответ

Решение

Правильнее всего сначала выяснить, какой раздел смонтирован. Затем вам нужно деактивировать другой, чтобы вы могли удалить диск с него. А затем увеличьте подключенный диск под mdadm, чтобы добавить на него новый диск, и программное обеспечение md синхронизирует подключенный в данный момент раздел с другим диском. После этого в cat'ing /proc/mdstat должно отображаться только одно устройство md с обоими указанными дисками (и, вероятно, еще одна синхронизация). (и починить fstab возможно)

Я не буду повторять многое из того, что здесь необходимо, так как вики linux raid довольно хороши и содержат большую часть документации, которую нужно прочитать (и с хорошими примерами).

Однако большинство людей забывают о том, что ядру linux необходим initramfs, содержащий необходимую информацию о диске. Поэтому каждый раз, когда вы изменяете конфигурацию md, разумно пересоздать initramfs, используя dracut:

dracut -v --mdadmconf new_image.img KERNEL-VERSION-STRING

А затем укажите grub на new_image.img.

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

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