Remplacer un disque défaillant de btrfs (RAID0 linear data allocation)

Cet article décrit la manipulation pour extraire un disque dur défaillant d’un système de fichiers btrfs créé en « linear data allocation » (aussi appelé RAID0) afin de le remplacer par un autre disque dur ou bien le transvaser sur les autres disques durs.

Cet article est incomplet car il donne plusieurs pistes pour réaliser cette opération, mais dans un cas de figure concret où plusieurs disques durs tombent en même temps sur un RAID0, je n’ai personnellement jamais réussi à retrouver le système de fichier en lecture-écriture (rw) mais seulement lecture simple (ro).

Contexte de la récupération

Dans le cas de figure de l’article, le système de fichier btrfs a été volontairement torturé avec un système de stockage non redondant et des disques durs de mauvaise qualité réputés en fin de vie. Le but étant de mettre à l’épreuve la stabilité du système de fichiers et sa résilience. Les commandes sont données à titre purement indicatif pour mon cas de figure, vous ne devez surtout par les reproduire sur votre ordinateur sous peine de détruire votre système de fichiers et de perdre vos données si quelque chose tourne mal.

Je vous demanderai de faire preuve de compréhension car je n’ai pas réellement fait le tour de la question, et je n’ai même pas réussi à finaliser ma restauration musclée dans le cas de 2 disques durs défaillants (ici sdg et sdf) sur un RAID0.

Les logs syslog ci-après indiquent de nombreux secteurs défectueux et des ré-allocations effectuées sur le système de fichiers, ici à cause de sdg et sdf.

 

L’ajout/retrait

La manipulation la plus évidente pour remplacer un disque dur est de commencer par ajouter un disque dur (ici sda) au système de fichiers (ici /data). Il est destiné à recevoir les données du disque dur défaillant.

Cette opération est normalement rapide car elle n’entraîne pas de déplacement de données.

Ensuite, nous allons tenter de retirer le disque dur défaillant.

Si tout se passe bien, cette commande prendra plusieurs heures ou dizaines d’heures à être complétée, et le disque sdg sera progressivement transvasé sur les autres disques durs.

On peut suivre l’avancement de l’opération avec la commande suivante

Là on voit que le disque dur sdg ne contient  plus que 368 GiB de données et le disque dur sda en contient 1,76 TiB. Normalement l’opération de retrait de disque dur se poursuit normalement jusqu’à vider totalement sdg.

Malheureusement pour moi le disque dur défaillant est vraiment défaillant et il ne me laissera pas copier tout son contenu. J’obtiens en effet le message suivant.

Nous arrivons aux limites de la manipulation couramment documentée par le wiki officiel. Le disque dur sdg est encore impliqué dans mon système de fichiers à hauteur de 368 Go, ce qui signifie que le volume de fichiers touchés est encore supérieur avec la répartition RAID0 sur les autres disques durs.

Nous pourrions tenter de ré-allouer manuellement le secteur défectueux grâce à son adresse LBA donnée par exemple par smartctl, ce n’est pas traité dans le cadre de cet article.

Le débranchement brutal

Quelque soit le type de metadata

Une alternative à cette opération d’ajout/retrait consiste à monter le système de fichiers en mode dégradé et de soustraire le disque dur manquant, quitte à perdre des données. Ici il y a 368 Go sur sdg, à multiplier par 6 disques avec le comportement du RAID0 soit 2,2 To perdus. Tant pis on vas tenter l’opération. Pour un RAID1 de données, aucune donnée ne serait perdue.

Pour commencer, je demande au contrôleur SATA de déconnecter l’interface. Cette commande est utile pour réaliser un hotswap « sécuritaire » ou bien permettre le manual swap lorsque le hotswap pose problème.

En regardant de plus près dans syslog on obtient quelque chose comme ceci. Le contrôleur disque stoppe sdg et btrfs détecte la perte et nous gratifie d’un joli message d’erreur qui indique que le montage en mode dégradé devient possible. Malheureusement pour moi, le disque sdg est défaillant (5 erreurs de lecture) mais le disque sdf l’est également (3 erreurs de lecture). Cela ne va pas nous aider.

Après cela, j’arrive encore à monter le système de fichiers en lecture seule. A l’issue de ce débranchement je constate qu’une bonne partie de fichiers est lisible partiellement avec des messages d’erreurs I/O. Si je vois ces fichiers avec ls, cela ne signifie pas que je pourrai lire tout leur contenu.

Le remontage en lecture-écriture m’est refusé.

Le message d’erreur dans dmesg est le suiant

Comme le système de fichiers est en lecture seule (ro), on en pourra pas demander à btrfs de soustraire le disque dur, opération qui nécessite un accès lecture-écriture (rw).

Dans la même idée si le disque dur est vraiment défectueux on peut demander son remplacement de cette manière.

Dommage pour moi, le disque sda a déjà été rempli, et cette commande permet de remplacer un disque existant (ou manquant) par un disque neuf (vide) qui sera totalement écrasé. De plus, cette commande nécessite les droits de lecture-écriture que je n’ai pas.

Passage aux metadata raid0

Dans mon cas de figure, je constate que mon système de fichier est hétéroclite avec deux méthodes de stockage des données (single et RAID0) et une méthode de stockage des metadata encore différente (RAID1).

Le type de redondance demandée à btrfs se consulte ainsi :

Dans mon cas de figure j’ai choisi RAID0 pour les données, ce qui correspond pour btrfs à « linear data allocation ». Pour les métadonnées RAID1 est supposé m’apporter une certaine redondance. Dans le cadre de cet article cette redondance n’est pas bienvenue car je veux monter le système de fichiers en lecture-écriture à tout prix quitte à perdre 2 To de données.

D’habitude avec le RAID0, si un disque dur est débranché, toute la grappe est perdue. Ici le disque dur sdg n’est plus impliqué dans la grappe qu’à hauteur de 368 Go (soit 2,2 To de fichiers concernés). On peut tout de même monter le système de fichiers en lecture seule, ce qui est en soi une bonne performance.

Je demande à btrfs de convertir l’array afin de perdre toute redondance de données sur les metadata. On a ainsi une chance que le système de fichiers puisse être monté en lecture-écriture.

On peut suivre l’avancement de l’opération avec la même commande qui indique la superposition de metadata en RAID1 et RAID0 le temps de la conversion.

De la même manière, l’allocation « single » a été créée par mkfs.btrfs et je vais tenter de la retirer en suivant cette commande issue du wiki officiel de btrfs.

De mon coté j’aurai eu l’idée de lancer plutôt cette commande suivante mais le -dconvert  semble nécessiter beaucoup de ressources et de temps. Si j’ai bien compris cette commande va équilibrer les disques durs au niveau de leur usage et forcer l’utilisation du stockage RAID0. Cela risquerait d’augmenter la part de données stockées par notre disque défectueux et dans mon cas de figure c’est déconseillé.

Lorsque l’opération est terminée on se retrouve avec ceci.

En réessayant de supprimer le disque dur « missing » nous avons, si j’ai bien compris, plus de chances de réussir l’opération car le système de fichier ne sera pas embêté par une quelconque redondance à conserver. Dans mon cas de figure où deux disques durs défaillent en même temps, btrfs est mis en grande difficulté et le système de fichier ne sera récupérable qu’en lecture seule.

Conclusion

Tout d’abord, je suis impressionné par la capacité de btrfs à monter un système de fichiers en lecture seule alors qu’un des disques durs imliqué dans le RAID0 est débranché. Il semble nécessaire de transvaser préalablement un maximum de données du disque dur défaillant avant de tenter un tel montage dégradé.

Une alternative au RAID0 pratiqué par btrfs, avec une capacité de restauration partielle à toute épreuve, ce serait unionfs par-dessus plusieurs disques ext4. Contrairement à unionfs, btrfs sera mis en grande difficulté en cas de défaillance d’un disque dur ou plusieurs.

Liens en rapport :

• btrfs device delete /dev/sdaX / » fails with error « ERROR: error removing the device ‘/dev/sdaX, bugs.launchpad.net (2011)