☰

mdadm полностью пересинхронизирует члена raid5, но теряется каждый раз после перезагрузки

tag-icon • tag-icon ubuntu raid mdadm
mdadm полностью пересинхронизирует члена raid5, но теряется каждый раз после перезагрузки

При установке win10 я мог случайно перезаписать на raid5члене (настройка из 3 дисков). Поэтому использовал ubuntu livecd, чтобы повторно добавить диск и повторно синхронизировать его (заняло 6 часов). Но после перезагрузки диск снова теряется из массива и не определяется как член рейда даже gparted. поэтому всю повторную синхронизацию пришлось повторить. Это уже случалось дважды.

Какой шаг я упускаю?

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sda[4] sdb[1] sde[3]
      3906764800 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
      [===========>.........]  recovery = 55.6% (1086304028/1953382400) finish=147.5min speed=97935K/sec
      bitmap: 0/15 pages [0KB], 65536KB chunk

unused devices: <none>

Подробности mdadm:

/dev/md1:
           Version : 1.2
     Creation Time : Sat Sep 21 14:09:01 2019
        Raid Level : raid5
        Array Size : 3906764800 (3725.78 GiB 4000.53 GB)
     Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
      Raid Devices : 3
     Total Devices : 3
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sat Jul 31 13:07:35 2021
             State : clean, degraded, recovering
    Active Devices : 2
   Working Devices : 3
    Failed Devices : 0
     Spare Devices : 1

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : bitmap

    Rebuild Status : 55% complete

              Name : vikas-asus-raid:1  (local to host vikas-asus-raid)
              UUID : ffe5d84b:45323883:86650996:ad3cb535
            Events : 44221

    Number   Major   Minor   RaidDevice State
       4       8        0        0      spare rebuilding   /dev/sda
       1       8       16        1      active sync   /dev/sdb
       3       8       64        2      active sync   /dev/sde

sudo parted -l:

Error: The primary GPT table is corrupt, but the backup appears OK, so that will
be used.
OK/Cancel? ok
Model: ATA WDC WD20EZRZ-00Z (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2000GB  2000GB  fat32


Error: /dev/sdb: unrecognised disk label
Model: ATA WDC WD20EURX-63T (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:

Model: ATA WDC WD20EZRX-00D (scsi)
Disk /dev/sdd: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start  End  Size  Type  File system  Flags


Model: WDC WD32 00BPVT-55ZEST0 (scsi)
Disk /dev/sde: 320GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type      File system     Flags
 1      1048kB  53.3GB  53.3GB  extended                  boot
 5      1049kB  53.3GB  53.3GB  logical   ext4
 3      53.3GB  102GB   49.2GB  primary   ext4
 2      102GB   202GB   100GB   primary   ext4
 4      308GB   320GB   11.8GB  primary   linux-swap(v1)


Model: Linux Software RAID Array (md)
Disk /dev/md1: 4001GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number  Start  End     Size    File system  Flags
 1      0.00B  4001GB  4001GB  ext4

решение1

Исправил сам. mdadm действует не так, как другие диски во время выключения. Суперблок mdadm никогда не записывался на диск автоматически. Он записывался при остановке mdadm. Видимо, система выключения должна это делать. Но mdadm не был изящным при выключении и потребовался полный тайм-аут в 1 мин. 30 с, чтобы быть принудительно завершенным. Поэтому перезагрузка не нашла диск снова.

Позже я остановил mdadm между синхронизацией. Это заставило его сбросить суперблок на диск. При следующей перезагрузке диск был автоматически найден, и неполная синхронизация даже возобновилась. После сброса суперблока, даже после синхронизации, все системы снова стали нормальными.

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

Связанный контент