Metadaten des Raubüberfalls, die nicht mit den Metadaten der einzelnen Laufwerke übereinstimmen?

Wir haben einen RAID 10 mit zwei ausgefallenen Laufwerken, wobei ein Laufwerk aus jedem Satz noch funktionsfähig ist.

Beim Booten in ein Rettungssystem scheinen die Metadaten in Ordnung zu sein und entsprechen dem erwarteten Zustand.

Die Metadaten von mdadm --detailmd lauten wie folgt:

 Version : 1.1 Creation Time : Mon Mar 16 15:53:57 2015 Raid Level : raid10 Used Dev Size : 975581184 (930.39 GiB 999.00 GB) Raid Devices : 4 Total Devices : 2 Persistence : Superblock is persistent  Update Time : Mon May 28 08:52:58 2018 State : active, FAILED, Not Started  Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0  Layout : near=2 Chunk Size : 512K  Name : 2 UUID : 34f4a5fa:4b8e03fa:3119b353:f45188a0 Events : 8618632  Number Major Minor RaidDevice State 0 8 1 0 active sync set-A /dev/sda1 1 8 17 1 active sync set-B /dev/sdb1 4 0 0 4 removed 6 0 0 6 removed 

Das init-System kann den Überfall nicht zusammenstellen, wobei der Kernel behauptet, dass es nicht genügend Spiegel gibt.

(...) md/raid10:md2: not enough operational mirrors. md: pers->run() failed ... dracut: mdadm: failed to start array /dev/md2: Input/output error (...) 

Wenn Sie versuchen, den Raid manuell zusammenzustellen ( mdadm --assemble --readonly --force /dev/md2 /dev/sd[ab]1), erhalten Sie Folgendes:

/dev/md2: Version : 1.1 Raid Level : raid0 Total Devices : 1 Persistence : Superblock is persistent  State : inactive  Name : 2 UUID : 34f4a5fa:4b8e03fa:3119b353:f45188a0 Events : 8618632  Number Major Minor RaidDevice  - 8 1 - /dev/sda1 

Wenn Sie --examinedie Metadaten der beteiligten Laufwerke überprüfen, erhalten Sie eine konsistente Ausgabe mit dem erwarteten Status (vor der manuellen Montage und danach):

/dev/sda1: Magic : a92b4efc Version : 1.1 Feature Map : 0x1 Array UUID : 34f4a5fa:4b8e03fa:3119b353:f45188a0 Name : 2 Creation Time : Mon Mar 16 15:53:57 2015 Raid Level : raid10 Raid Devices : 4  Avail Dev Size : 1951162368 (930.39 GiB 999.00 GB) Array Size : 1951162368 (1860.77 GiB 1997.99 GB) Data Offset : 262144 sectors Super Offset : 0 sectors Unused Space : before=262064 sectors, after=0 sectors State : clean Device UUID : 89288c87:2cf8f6cd:483328b4:fffb3db6  Internal Bitmap : 8 sectors from superblock Update Time : Mon May 28 08:52:58 2018 Bad Block Log : 512 entries available at offset 72 sectors Checksum : eaf59503 - correct Events : 8618632  Layout : near=2 Chunk Size : 512K  Device Role : Active device 0 Array State : AAA. ('A' == active, '.' == missing, 'R' == replacing) 

Wir sind uns bewusst, dass das dritte aktive Laufwerk entfernt wurde, dies sollte jedoch nicht der Grund für das Problem sein.

Unsere zwei Hauptfragen sind also:

1. Warum stimmt der Status des Arrays nicht mit den einzelnen Laufwerken überein?
2. Wie kann das gelöst werden?

Für das Protokoll: CentOS 6 mit einer Kernel-Version 2.6.32-696.30.1.el6.x86_64