☰

mdadm synchronisiert das raid5-Mitglied vollständig neu, verliert aber jedes Mal nach dem Neustart

tag-icon • tag-icon ubuntu raid mdadm
mdadm synchronisiert das raid5-Mitglied vollständig neu, verliert aber jedes Mal nach dem Neustart

Während der Installation von Win10 habe ich möglicherweise versehentlich ein raid5Mitglied überschrieben (Setup mit 3 Festplatten). Ich habe also Ubuntu LiveCD verwendet, um die Festplatte erneut hinzuzufügen und erneut zu synchronisieren (dauerte 6 Stunden). Aber nach dem Neustart ist die Festplatte wieder aus dem Array verschwunden und wird nicht einmal von als RAID-Mitglied erkannt gparted. Daher musste die gesamte Neusynchronisierung erneut durchgeführt werden. Ist bereits zweimal passiert.

Welcher Schritt fehlt mir?

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-Details:

/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

Antwort1

Habe es selbst repariert. mdadm verhält sich beim Herunterfahren anders als andere Festplatten. Der mdadm-Superblock wurde nie automatisch auf die Festplatte geschrieben. Er wurde geschrieben, als mdadm gestoppt wurde. Anscheinend sollte das ein Shutdown-System tun. Aber mdadm war beim Herunterfahren nicht ordnungsgemäß und benötigte eine volle 1m:30s-Zeitüberschreitung, um zwangsweise beendet zu werden. Der Neustart hat die Festplatte also nicht wiedergefunden.

Später habe ich mdadm zwischen den Synchronisierungen gestoppt. Dadurch wurde der Superblock auf die Festplatte geschrieben. Beim nächsten Neustart wurde die Festplatte automatisch gefunden und die unvollständige Synchronisierung wurde sogar fortgesetzt. Nachdem der Superblock gelöscht war, funktionierten alle Systeme auch nach der Synchronisierung wieder normal.

Ich weiß immer noch nicht, was mein Fehler für dieses Verhalten war. Aber ich bin froh, dass das geklärt wurde. Ein degradiertes Raid5-Array ist wie ein hängendes Schwert.

verwandte Informationen