Pourquoi mdadm --add échoue avec « add new device failed ... Invalid argument » alors que le disque est sain ?

Regardez dmesg juste après : si le noyau écrit « does not have a valid v1.2 superblock, not importing! » avec md_import_device returned -22, ce n’est pas le disque mais le superbloc que mdadm vient d’écrire qui est rejeté. Vérifiez le Feature Map avec mdadm --examine : la valeur 0x8 indique que le Bad Block Log est actif, et c’est lui qui fait capoter la validation du superbloc à l’import.

C’est quoi le Bad Block Log (BBL) de mdadm et pourquoi pose-t-il problème ?

Le Bad Block Log est une fonctionnalité des métadonnées md 1.2 qui enregistre les secteurs défectueux par disque pour les contourner. Activé par défaut depuis mdadm 3.3, il a un historique de bugs d’interopérabilité : quand un membre a des bad blocks enregistrés, l’ajout d’un nouveau membre peut être rejeté par le noyau. Beaucoup d’admins le désactivent purement et simplement.

Quelle différence entre mdadm --update=no-bbl et --update=force-no-bbl ?

no-bbl retire le Bad Block Log mais refuse de le faire s’il contient des entrées (des secteurs marqués défectueux), pour ne pas perdre cette information. force-no-bbl le retire même avec des entrées présentes. N’utilisez force-no-bbl qu’avec une copie de secours des données, car les blocs auparavant marqués mauvais ne seront plus contournés.

Le Bad Block Log peut-il se remplir tout seul à cause d’une alimentation ou d’un câble défaillant ?

Oui. Une écriture qui échoue à cause d’une alim instable ou d’un câble marginal est enregistrée par md comme un bad block, même si le secteur est physiquement sain. Après réparation du matériel, ces entrées sont souvent des artefacts : vérifiez avec mdadm --examine-badblocks et un fsck -n, et ré-écrivez la zone (le resync s’en charge) pour laisser le disque réallouer si besoin.

`mdadm --add` en échec : le Bad Block Log en cause

Je remplace un disque de 2 To par un 6 To dans un miroir RAID1. Pour éviter de manipuler le NAS, je sors les disques et je fais tout depuis un PC via des adaptateurs USB-SATA : mdadm réassemble les arrays par UUID, peu importe la machine. Je clone la table de partitions du disque source vers le neuf, puis j’ajoute les trois membres (root, swap, data) aux trois arrays.

root et swap s’ajoutent sans broncher. Le membre data, lui, refuse :

$ sudo mdadm --add /dev/md125 /dev/sdb4; echo "rc=$?"
mdadm: add new device failed for /dev/sdb4 as 3: Invalid argument
rc=1

Invalid argument. La partition fait pourtant la bonne taille (identique au disque source, table clonée), et le disque neuf lit à 220 Mo/s sans une erreur.

Les fausses pistes

J’ai brûlé une heure sur des théories plausibles mais fausses :

Le bitmap : seul l’array data a un write-intent bitmap. Je le retire (--bitmap=none) → même échec.
Le data offset : mdadm --examine montre Data Offset: 264192 sectors. J’essaie de le forcer sur le nouveau membre → mdadm: :option --data-offset not valid in manage mode.
Un secteur illisible dans la zone métadonnées : je ré-écris les 300 premiers Mo de la partition pour forcer une réallocation → même échec.
La taille : j’agrandis même l’array à la taille max du device (--grow --size=max) pour aligner Used = Avail → toujours Invalid argument.

Le vrai diagnostic : lire ce que dit le noyau

Le driver md loggue toujours la raison du rejet. Il suffisait de regarder :

$ sudo dmesg | tail
md: sdb4 does not have a valid v1.2 superblock, not importing!
md: md_import_device returned -22

-22, c’est EINVAL. Le noyau rejette le superbloc que mdadm vient d’écrire comme invalide. Or mdadm --examine arrive à le lire… La différence se voit dans le Feature Map :

$ sudo mdadm --examine /dev/sda4 | grep -iE "Feature Map|Bad Block"
    Feature Map : 0x8
  Bad Block Log : 512 entries available at offset 16 sectors - bad blocks present.

Feature Map: 0x8 = Bad Block Log actif, avec des bad blocks présents. L’array utilise le BBL, et les deux disques ont des secteurs enregistrés dedans. Quand mdadm --add écrit un superbloc portant le BBL sur le nouveau membre, le noyau le rejette à l’import — un bug d’interopérabilité connu du Bad Block Log.

Le détail qui confirme que ce n’est pas le disque : le membre sain, qui fonctionne parfaitement, a lui aussi Feature Map: 0x8 avec des bad blocks. Le BBL n’est pas fatal en soi — c’est l’écriture d’un superbloc BBL sur un nouveau membre qui échoue.

Le fix : supprimer le Bad Block Log de l’array

Comme des bad blocks sont présents, --update=no-bbl refusera. Il faut force-no-bbl, en réassemblant l’array (dégradé, sur le seul membre restant) :

# 1. Voir ce qu'on va perdre (liste des bad blocks)
sudo mdadm --examine-badblocks /dev/sda4
#   61426920 for 8 sectors
#   3638949624 for 8 sectors
#   ... (une dizaine d'entrées de 8 secteurs = ~40 Ko)

# 2. Réassembler en supprimant le BBL
sudo mdadm --stop /dev/md125
sudo mdadm --assemble /dev/md125 /dev/sda4 --update=force-no-bbl

# 3. Vérifier que le BBL a disparu
sudo mdadm --examine /dev/sda4 | grep "Feature Map"
#     Feature Map : 0x0

# 4. Ajouter le nouveau membre — cette fois ça passe
sudo mdadm --add /dev/md125 /dev/sdb4; echo "rc=$?"
#   mdadm: added /dev/sdb4
#   rc=0

Dernier piège : le membre s’ajoute mais reste en (S) (spare) sans démarrer la recovery, parce que l’array est en auto-read-only. Un coup de fouet :

sudo mdadm --readwrite /dev/md125
cat /proc/mdstat
#   md125 : active raid1 sdb4[3] sda4[2]
#         [>....................]  recovery = 0.1% ...

Faut-il s’inquiéter des bad blocks perdus ?

force-no-bbl oublie les secteurs marqués mauvais : ils ne seront plus contournés. Deux cas :

Artefacts (écritures ratées sous alim/câble défaillant) : le secteur est physiquement sain, l’entrée BBL est du bruit. C’était mon cas — une dizaine de blocs apparus pile pendant que l’alim du NAS agonisait.
Vrais défauts média : lire ces blocs renverra des données douteuses.

Dans les deux cas, on se protège pareil : avant le force-no-bbl, garder une copie saine des données (ici l’ancien disque de 2 To, débranché et intact), et après le resync, relancer un fsck -n sur le filesystem pour confirmer l’intégrité. Un secteur physiquement mauvais sera de toute façon réalloué par le disque au premier resync qui écrit dessus.

Lessons learned

add new device failed ... Invalid argument ≠ disque HS. Le message est trompeur : la vérité est dans dmesg : « does not have a valid v1.2 superblock … -22 ».
Feature Map: 0x8 dans mdadm --examine = Bad Block Log actif. C’est le premier truc à checker sur un --add qui refuse.
mdadm --examine-badblocks liste les secteurs enregistrés — utile pour jauger le risque avant de désactiver le BBL.
no-bbl refuse si des blocs sont présents ; force-no-bbl force — à faire avec une copie de secours.
Le BBL se remplit sous panne électrique : une alim mourante génère des écritures ratées enregistrées comme bad blocks, qui ne sont souvent que des artefacts.
Un RAID1 se répare sur n’importe quel PC Linux : mdadm assemble par UUID via de simples adaptateurs USB-SATA, aucune dépendance à la machine d’origine.