mdadm - устаревший массив и текущий массив имеют одинаковый UUID. Текущий массив не собирается при загрузке

Question

mdadm - устаревший массив и текущий массив имеют одинаковый UUID. Текущий массив не собирается при загрузке

Я редко задаю вопросы, но Google нашел пробел в этом вопросе, так что я здесь.

У меня проблема с моим программным обеспечением mdadm Raid, работающим на Ubuntu 14.04 Server Edition. В частности, мне кажется, что у меня установлено 2 RAID-массива с одинаковым UUID, один из которых старый, а другой новый, что означает, что он не может быть собран при загрузке, что приводит к зависанию загрузки, так как он не может смонтировать некоторые из моих файловых систем.

Я подробно опишу то, что я сделал, и где я думаю, что этот вопрос представил себя. То, что я ищу, - это как очистить детали устаревшего массива, чтобы мой Raid правильно собирался при загрузке.

В далеком прошлом, когда у меня был массив Raid1, состоящий из двух дисков по 2 ТБ. Система не находится в этом массиве, у нее есть выделенный диск, так что это чисто для данных.

Я начал исчерпывать пространство, поэтому перенес эти два диска в Raid5. Все идет нормально.

Затем я расширил свой массив, добавив 2 запасных части по 2 ТБ и увеличив массив в эти запасные части. Вот где я думаю, что проблема произошла.

Затем я решил, учитывая размер массива и время перестроения, я бы предпочел запустить Raid6, поэтому я разделил 2 существующих диска емкостью 1 ТБ, чтобы получить Raid0 объемом 2 ТБ, и увеличил Raid 6 на этих дисках. Вот где я сейчас нахожусь: Raid 6, состоящий из 4 дисков по 2 ТБ + 1 X 2 ТБ, Raid 0 (всего 10 ТБ, 6 ТБ используемого пространства, четность 4 ТБ).

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

sudo mdadm --examine --scan -v
ARRAY /dev/md/1 level=raid0 metadata=1.2 num-devices=2 UUID=913834a2:63afa2cd:a84e864a:96353af5 name=fileserver:1
   devices=/dev/sdd1,/dev/sda1
ARRAY /dev/md/0 level=raid5 metadata=1.2 num-devices=2 UUID=18235f5c:bd4892c0:7616a677:626ae2e8 name=team-canfield:0
   spares=2   devices=/dev/sde,/dev/sdf
ARRAY /dev/md/0 level=raid6 metadata=1.2 num-devices=5 UUID=18235f5c:bd4892c0:7616a677:626ae2e8 name=team-canfield:0
   devices=/dev/sdg1,/dev/sdh1,/dev/sde1,/dev/sdf1,/dev/md/1

Видите те 2 /dev/md0 с разными уровнями рейда, но с тем же UUID? Отстой, да? Похоже, что Raid5 с двумя запасными частями остался в конфигурации и не был перезаписан путем увеличения одного и того же массива на эти две запасные части и впоследствии в Raid6. Важно то, что я, возможно, облажался, если мой исходный массив ссылался на целые диски (/dev/sd[ef]), а мой Raid6 ссылался на целые разделы диска (/dev/sd[efgh]1).

В результате я не могу собрать массив, используя:

sudo mdadm --assemble --scan

поскольку он пытается собрать Raid5 с 2 запасными частями и не может завершить. Вместо этого я должен выдать следующее для сборки массива:

sudo mdadm --assemble /dev/md0 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/md1

Это прекрасно работает, и мой Raid6 снова становится доступным в /dev/md0... ОДНАКО, это означает, что мой сервер теперь требует ручного вмешательства, когда он не может смонтировать файловые системы в Raid при загрузке, что невероятно неудобно, так как это означает, что Я должен физически перейти на сервер, чтобы [S] уничтожить неудачное монтирование.

Ниже приведены выходные данные моего conf-файла и другие выходные данные mdadm (пока мой Raid6 успешно работает), чтобы помочь в дальнейшей диагностике решения.

mdstat:

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdg1[0] md1[5] sdf1[3] sde1[4] sdh1[2]
      5860145664 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU]

md1 : active raid0 sdd1[1] sda1[0]
      1953522688 blocks super 1.2 512k chunks

unused devices: <none>

mdadm - деталь

sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Fri Sep  4 00:57:56 2015
     Raid Level : raid6
     Array Size : 5860145664 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 1953381888 (1862.89 GiB 2000.26 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

    Update Time : Sun Sep 27 14:00:17 2015
          State : clean
 Active Devices : 5
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : team-canfield:0  (local to host team-canfield)
           UUID : 18235f5c:bd4892c0:7616a677:626ae2e8
         Events : 1231852

    Number   Major   Minor   RaidDevice State
       0       8       97        0      active sync   /dev/sdg1
       2       8      113        1      active sync   /dev/sdh1
       4       8       65        2      active sync   /dev/sde1
       3       8       81        3      active sync   /dev/sdf1
       5       9        1        4      active sync   /dev/md/1

mdadm.conf:

cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/1 metadata=1.2 UUID=913834a2:63afa2cd:a84e864a:96353af5 name=fileserver:1
ARRAY /dev/md/0 metadata=1.2 UUID=18235f5c:bd4892c0:7616a677:626ae2e8 name=team-canfield:0

mdadm --examine --scan -vvvv:

sudo mdadm --examine --scan -vvvv
mdadm: No md superblock detected on /dev/md0.
/dev/sdg1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 18235f5c:bd4892c0:7616a677:626ae2e8
           Name : team-canfield:0  (local to host team-canfield)
  Creation Time : Fri Sep  4 00:57:56 2015
     Raid Level : raid6
   Raid Devices : 5

 Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
     Array Size : 5860145664 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 3906763776 (1862.89 GiB 2000.26 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : e39fa659:9010941e:034e58b6:f88f7542

    Update Time : Sun Sep 27 14:00:17 2015
       Checksum : 18244273 - correct
         Events : 1231852

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AAAAA ('A' == active, '.' == missing)
/dev/sdg:
   MBR Magic : aa55
Partition[0] :   3907027120 sectors at         2048 (type fd)
/dev/sdh1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 18235f5c:bd4892c0:7616a677:626ae2e8
           Name : team-canfield:0  (local to host team-canfield)
  Creation Time : Fri Sep  4 00:57:56 2015
     Raid Level : raid6
   Raid Devices : 5

 Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
     Array Size : 5860145664 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 3906763776 (1862.89 GiB 2000.26 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : cc416705:bf6220eb:9201a515:c044aabd

    Update Time : Sun Sep 27 14:00:17 2015
       Checksum : 6af29ee4 - correct
         Events : 1231852

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AAAAA ('A' == active, '.' == missing)
/dev/sdh:
   MBR Magic : aa55
Partition[0] :   3907027120 sectors at         2048 (type fd)
/dev/sde1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 18235f5c:bd4892c0:7616a677:626ae2e8
           Name : team-canfield:0  (local to host team-canfield)
  Creation Time : Fri Sep  4 00:57:56 2015
     Raid Level : raid6
   Raid Devices : 5

 Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
     Array Size : 5860145664 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 3906763776 (1862.89 GiB 2000.26 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : dbd3c13e:269dde52:0b07e3cf:d8d2e4fc

    Update Time : Sun Sep 27 14:00:17 2015
       Checksum : 583feee - correct
         Events : 1231852

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAAAA ('A' == active, '.' == missing)
/dev/sde:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 18235f5c:bd4892c0:7616a677:626ae2e8
           Name : team-canfield:0  (local to host team-canfield)
  Creation Time : Fri Sep  4 00:57:56 2015
     Raid Level : raid5
   Raid Devices : 2

 Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
     Array Size : 1953381888 (1862.89 GiB 2000.26 GB)
  Used Dev Size : 3906763776 (1862.89 GiB 2000.26 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 8089c55e:df3a826b:7df2e4b9:dbff7a97

    Update Time : Sat Sep  5 14:59:00 2015
       Checksum : 7f43d8a - correct
         Events : 514

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : spare
   Array State : AA ('A' == active, '.' == missing)
/dev/sdf1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 18235f5c:bd4892c0:7616a677:626ae2e8
           Name : team-canfield:0  (local to host team-canfield)
  Creation Time : Fri Sep  4 00:57:56 2015
     Raid Level : raid6
   Raid Devices : 5

 Avail Dev Size : 3906764976 (1862.89 GiB 2000.26 GB)
     Array Size : 5860145664 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 3906763776 (1862.89 GiB 2000.26 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : de9ae300:e4382032:a5fd89c9:c966255b

    Update Time : Sun Sep 27 14:00:17 2015
       Checksum : feceec37 - correct
         Events : 1231852

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 3
   Array State : AAAAA ('A' == active, '.' == missing)
/dev/sdf:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 18235f5c:bd4892c0:7616a677:626ae2e8
           Name : team-canfield:0  (local to host team-canfield)
  Creation Time : Fri Sep  4 00:57:56 2015
     Raid Level : raid5
   Raid Devices : 2

 Avail Dev Size : 3906767024 (1862.89 GiB 2000.26 GB)
     Array Size : 1953381888 (1862.89 GiB 2000.26 GB)
  Used Dev Size : 3906763776 (1862.89 GiB 2000.26 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 3b86b670:f4812448:e474f7b5:b214454c

    Update Time : Sat Sep  5 14:49:56 2015
       Checksum : a7651675 - correct
         Events : 513

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : spare
   Array State : AA ('A' == active, '.' == missing)
/dev/sdd1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 913834a2:63afa2cd:a84e864a:96353af5
           Name : fileserver:1
  Creation Time : Thu Sep 10 11:52:39 2015
     Raid Level : raid0
   Raid Devices : 2

 Avail Dev Size : 1953523104 (931.51 GiB 1000.20 GB)
    Data Offset : 16 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 8745a084:7e031e4f:da72b198:e548d755

    Update Time : Thu Sep 10 11:52:39 2015
       Checksum : 48772d61 - correct
         Events : 0

     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing)
/dev/sdd:
   MBR Magic : aa55
Partition[0] :   1953523120 sectors at         2048 (type 83)
mdadm: No md superblock detected on /dev/sdc1.
/dev/sdc:
   MBR Magic : aa55
Partition[0] :    976771072 sectors at         2048 (type 83)
mdadm: No md superblock detected on /dev/dm-2.
mdadm: No md superblock detected on /dev/dm-1.
mdadm: No md superblock detected on /dev/dm-0.
mdadm: No md superblock detected on /dev/sdb5.
/dev/sdb2:
   MBR Magic : aa55
Partition[0] :   1953021952 sectors at            2 (type 8e)
mdadm: No md superblock detected on /dev/sdb1.
/dev/sdb:
   MBR Magic : aa55
Partition[0] :       497664 sectors at         2048 (type 83)
Partition[1] :   1953021954 sectors at       501758 (type 05)
/dev/md/1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 18235f5c:bd4892c0:7616a677:626ae2e8
           Name : team-canfield:0  (local to host team-canfield)
  Creation Time : Fri Sep  4 00:57:56 2015
     Raid Level : raid6
   Raid Devices : 5

 Avail Dev Size : 3906783232 (1862.90 GiB 2000.27 GB)
     Array Size : 5860145664 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 3906763776 (1862.89 GiB 2000.26 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : cc54a0b1:0a5cf703:e7e0b1d2:0bab9231

    Update Time : Sun Sep 27 14:00:17 2015
       Checksum : 60f83822 - correct
         Events : 1231852

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 4
   Array State : AAAAA ('A' == active, '.' == missing)
/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 913834a2:63afa2cd:a84e864a:96353af5
           Name : fileserver:1
  Creation Time : Thu Sep 10 11:52:39 2015
     Raid Level : raid0
   Raid Devices : 2

 Avail Dev Size : 1953523104 (931.51 GiB 1000.20 GB)
    Data Offset : 16 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 8e41dd73:0e90d173:852facd8:f3009a34

    Update Time : Thu Sep 10 11:52:39 2015
       Checksum : 7b252ab0 - correct
         Events : 0

     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing)
/dev/sda:
   MBR Magic : aa55
Partition[0] :   1953523120 sectors at         2048 (type 83)

Последний показывает диски / dev / sd [ef], являющиеся частью Raid5, в то время как их основной (и единственный) раздел является частью Raid6.

Итак, есть ли способ, не теряя мои данные, я могу уничтожить информацию Raid5? У меня нет места для резервного копирования, чтобы перестроить мой массив и скопировать все обратно.

Я думаю, я мог бы обновить mdadm.conf следующим образом:

DEVICE partitions

и он проигнорирует Raid5, однако, я чувствую, что это просто покрывает трещины, и я, несомненно, снова столкнусь с подобными проблемами в следующий раз, когда я изменю свою конфигурацию Raid. На самом деле, я просто хочу уничтожить все свидетельства этого фантомного Raid5 с тем же UUID, что и у моего активного Raid6. Любой берущий?

Большое спасибо!

2

mount raid mdadm

Источник

Torz77 27 сен '15 в 13:17

1 ответ

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

Torz77 02 окт '15 в 00:13 2015-10-02 00:13 · Answer 1 · 2015-10-02 00:13

Хорошо, я думаю, что исправил это. Я пойду через шаги, которые предпринял, если у кого-то еще возникнет эта проблема. Кроме того, эта техника опасна, так как в настоящее время я использую ухудшенный массив Raid6 из 3 частей по 5.

Остановить массив:

$ sudo mdadm --stop /dev/md0
 mdadm: stopped /dev/md0

Обнулить суперблок с первого диска в устаревшем массиве Raid5

$ sudo mdadm --zero-superblock /dev/sdf

Изучите массивы, чтобы увидеть, удалил ли он его:

$ sudo mdadm --examine --scan -v
ARRAY /dev/md/1 level=raid0 metadata=1.2 num-devices=2 UUID=913834a2:63afa2cd:a84e864a:96353af5 name=fileserver:1
   devices=/dev/sdd1,/dev/sda1
ARRAY /dev/md/0 level=raid5 metadata=1.2 num-devices=2 UUID=18235f5c:bd4892c0:7616a677:626ae2e8 name=team-canfield:0
   spares=1   devices=/dev/sde
ARRAY /dev/md/0 level=raid6 metadata=1.2 num-devices=5 UUID=18235f5c:bd4892c0:7616a677:626ae2e8 name=team-canfield:0
   devices=/dev/sdg1,/dev/sdh1,/dev/md/1

Странно, что я потерял оба раздела (sd[ef]1) из моего Raid6 на этом этапе. Но хорошо, что Raid5 просто шел с одним запасным.

Обнулить оставшийся суперблок:

$ sudo mdadm --zero-superblock /dev/sde

Проверьте еще раз:

$ sudo mdadm --examine --scan -v
ARRAY /dev/md/1 level=raid0 metadata=1.2 num-devices=2 UUID=913834a2:63afa2cd:a84e864a:96353af5 name=fileserver:1
   devices=/dev/sdd1,/dev/sda1
ARRAY /dev/md/0 level=raid6 metadata=1.2 num-devices=5 UUID=18235f5c:bd4892c0:7616a677:626ae2e8 name=team-canfield:0
   devices=/dev/sdg1,/dev/sdh1,/dev/md/1

Устаревший Raid5 теперь исчез. Теперь момент истины, возможно ли восстановить разделы обратно в Raid6:

$ sudo mdadm --assemble /dev/md0 /dev/sdg1 /dev/sdh1 /dev/md1 /dev/sde1 /dev/sdf1 --force
mdadm: cannot open device /dev/sde1: No such file or directory
mdadm: /dev/sde1 has no superblock - assembly aborted

$ sudo mdadm --assemble /dev/md0 /dev/sdg1 /dev/sdh1 /dev/md1 /dev/sdf1 --force
mdadm: cannot open device /dev/sdf1: No such file or directory
mdadm: /dev/sdf1 has no superblock - assembly aborted

Нет, это не так:/ Это плохие новости, и я боюсь худшего за мои данные. Попробуйте собрать 3 оставшихся раздела:

$ sudo mdadm --assemble /dev/md0 /dev/sdg1 /dev/sdh1 /dev/md1  --force
mdadm: /dev/md0 has been started with 3 drives (out of 5).

Уф! Успех!

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdg1[0] md1[5] sdh1[2]
      5860145664 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/3] [UU__U]

md1 : active raid0 sdd1[1] sda1[0]
      1953522688 blocks super 1.2 512k chunks

Хорошо, мы серьезно деградировали, но по крайней мере он построен. Я монтирую массив, чтобы убедиться, что мои данные не повреждены, и с облегчением вздыхаю, когда вижу, что все еще там. NB. На данном этапе может быть не стоит монтировать массив. Я думаю, что это может быть различием между возможностью выпустить --re-add, а не --add позже на этих шагах.

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

Когда он возвращается в интернет, я снова проверяю:

$ sudo mdadm --examine --scan -v
ARRAY /dev/md/1 level=raid0 metadata=1.2 num-devices=2 UUID=913834a2:63afa2cd:a84e864a:96353af5 name=fileserver:1
   devices=/dev/sdd1,/dev/sda1
ARRAY /dev/md/0 level=raid6 metadata=1.2 num-devices=5 UUID=18235f5c:bd4892c0:7616a677:626ae2e8 name=team-canfield:0
   devices=/dev/sdg1,/dev/sdh1,/dev/sdf1,/dev/sde1,/dev/md/1

Может ли это быть? Теперь он видит все 5 разделов Raid6, а Raid5 нигде не видно.

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : inactive sdg1[0](S) sdh1[2](S) sde1[4](S) sdf1[3](S)
      7813529952 blocks super 1.2

md1 : active raid0 sdd1[1] sda1[0]
      1953522688 blocks super 1.2 512k chunks

unused devices: <none>

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

Ну, у нас это далеко. Давайте остановим массив:

$ sudo mdadm --stop /dev/md0
mdadm: stopped /dev/md0

И попытка собрать скан:

$ sudo mdadm --assemble --scan

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdg1[0] md1[5] sdh1[2]
      5860145664 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/3] [UU__U]

md1 : active raid0 sdd1[1] sda1[0]
      1953522688 blocks super 1.2 512k chunks

Удивительно! Мы снова в сети, и я впервые смог успешно выполнить эту команду с тех пор, как перешел с Raid5 на Raid6. Мы, однако, по-прежнему деградировали, так как /dev/sd[ef]1 нигде не видно.

Я остановлю массив и попытаюсь принудительно собрать его, явно назвав разделы-члены:

$ sudo mdadm --stop /dev/md0
mdadm: stopped /dev/md0

$ sudo mdadm --assemble /dev/md0 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 /dev/md1 -v --force
mdadm: looking for devices for /dev/md0
mdadm: /dev/sde1 is identified as a member of /dev/md0, slot 2.
mdadm: /dev/sdf1 is identified as a member of /dev/md0, slot 3.
mdadm: /dev/sdg1 is identified as a member of /dev/md0, slot 0.
mdadm: /dev/sdh1 is identified as a member of /dev/md0, slot 1.
mdadm: /dev/md1 is identified as a member of /dev/md0, slot 4.
mdadm: added /dev/sdh1 to /dev/md0 as 1
mdadm: added /dev/sde1 to /dev/md0 as 2 (possibly out of date)
mdadm: added /dev/sdf1 to /dev/md0 as 3 (possibly out of date)
mdadm: added /dev/md1 to /dev/md0 as 4
mdadm: added /dev/sdg1 to /dev/md0 as 0
mdadm: /dev/md0 has been started with 3 drives (out of 5).

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

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdg1[0] md1[5] sdh1[2]
      5860145664 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/3] [UU__U]

md1 : active raid0 sdd1[1] sda1[0]
      1953522688 blocks super 1.2 512k chunks

unused devices: <none>

$ sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Fri Sep  4 00:57:56 2015
     Raid Level : raid6
     Array Size : 5860145664 (5588.67 GiB 6000.79 GB)
  Used Dev Size : 1953381888 (1862.89 GiB 2000.26 GB)
   Raid Devices : 5
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Thu Oct  1 23:57:14 2015
          State : clean, degraded
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : team-canfield:0  (local to host team-canfield)
           UUID : 18235f5c:bd4892c0:7616a677:626ae2e8
         Events : 1231860

    Number   Major   Minor   RaidDevice State
       0       8       97        0      active sync   /dev/sdg1
       2       8      113        1      active sync   /dev/sdh1
       2       0        0        2      removed
       3       0        0        3      removed
       5       9        1        4      active sync   /dev/md/1

Итак, они вернулись в удаленном состоянии. Давайте попробуем добавить их заново:

$ sudo mdadm --manage /dev/md0 --re-add /dev/sd[ef]1
mdadm: --re-add for /dev/sde1 to /dev/md0 is not possible

$ sudo mdadm --manage /dev/md0 --re-add /dev/sdf1
mdadm: --re-add for /dev/sdf1 to /dev/md0 is not possible

Блин конечно нет. Что ж, давайте рассмотрим события в разделах, чтобы увидеть, действительно ли они распознаются как часть массива:

$ sudo mdadm --examine /dev/sd[a-z]1 | egrep 'Event|/dev/sd'
mdadm: No md superblock detected on /dev/sdb1.
mdadm: No md superblock detected on /dev/sdc1.
/dev/sda1:
         Events : 0
/dev/sdd1:
         Events : 0
/dev/sde1:
         Events : 1231852
/dev/sdf1:
         Events : 1231852
/dev/sdg1:
         Events : 1231860
/dev/sdh1:
         Events : 1231860

Хорошо, очевидно, всего 8 событий из 1.2m достаточно, чтобы сделать --re-add невозможным. Это позор, и, вероятно, я установил рейд, чтобы проверить, что он все еще не поврежден ранее, в противном случае, похоже, мне действительно удалось обнулить суперблоки с удаленных дисков, оставив при этом суперблоки и данные на разделах нетронутыми (Я, очевидно, на самом деле не знаю, как работают суперблоки).

Что ж, на данный момент нет другого выбора, кроме как добавить два раздела обратно в массив и позволить ему перестроить:

$ sudo mdadm --manage /dev/md0 --add /dev/sd[ef]1
mdadm: added /dev/sde1
mdadm: added /dev/sdf1

Отлично! Теперь давайте проверим прогресс:

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid6 sdf1[7] sde1[6] sdg1[0] md1[5] sdh1[2]
      5860145664 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/3] [UU__U]
      [>....................]  recovery =  0.0% (84312/1953381888) finish=1930.4min speed=16862K/sec

md1 : active raid0 sdd1[1] sda1[0]
      1953522688 blocks super 1.2 512k chunks

День постройки не так уж и плох, поскольку для перехода с Raid5 на Raid6 потребовалось 7 дней. Это будет страшно 24 часа, так как я молюсь, чтобы ничего не случилось с моим массивом во время процесса восстановления, но похоже, что это успех.

Итак, мы узнали:

Raid6, как и ожидалось, прекрасно работает, когда теряет 2 раздела из 5
Не смешивайте ваши диски и разделы при использовании mdadm.