Metadados da invasão comprometida inconsistentes com os metadados das unidades individuais?

Question

Temos um ataque 10 com dois drives com falha, com um drive de cada conjunto ainda funcional.

Ao inicializar no sistema de recuperação, os metadados parecem estar bem e consistentes com o estado esperado.

Os metadados de mdadm --detail do md são os seguintes:

  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

O sistema init não pode montar o ataque, com o kernel afirmando que não há espelhos suficientes.

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

Tentando montar o ataque manualmente ( mdadm --assemble --readonly --force /dev/md2 /dev/sd[ab]1 ) gera o seguinte:

/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

A verificação com --examine dos metadados das unidades participantes nos fornece uma saída consistente com o estado esperado (antes da montagem manual e depois):

/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)

Estamos cientes de que o terceiro disco ativo foi removido, mas isso não deve ser a raiz do problema.

Portanto, nossas duas principais perguntas são:

1. Por que o estado da matriz é inconsistente com as unidades individuais?
2. Como isso pode ser resolvido?

Para o registro: CentOS 6 com uma versão do kernel 2.6.32-696.30.1.el6.x86_64