Voici une manipulation réalisée dans le but de retirer un disque dur défaillant d’une array RAID1 crée avec Btrfs. Aucune donnée ne doit normalement être perdue grâce à la redondance permise pas le RAID1. Cet article fait suite à mes précédentes difficultés pour restaurer des données issues d’un RAID0 Btrfs, situation bien plus délicate.
Si vous souhaitez utiliser ses informations pour vous-mêmes, je vous conseille fortement de sauvegarder vos données préalablement.
Constatation de la panne
Sur une grappe de stockage redondée RAID1 grâce à Btrfs (et non pas mdadm) je me rends compte que le système de fichiers ne veut pas se monter au démarrage. Des messages d’erreur assaillent mon kern.log.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
May 2 10:29:21 serveur kernel: [939887.012395] ata9.00: exception Emask 0x0 SAct 0x38000 SErr 0x0 action 0x6 frozen May 2 10:29:21 serveur kernel: [939887.012415] ata9.00: failed command: READ FPDMA QUEUED May 2 10:29:21 serveur kernel: [939887.012432] ata9.00: cmd 60/20:78:c0:e3:ee/00:00:f5:00:00/40 tag 15 ncq 16384 in May 2 10:29:21 serveur kernel: [939887.012432] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) May 2 10:29:21 serveur kernel: [939887.012453] ata9.00: status: { DRDY } May 2 10:29:21 serveur kernel: [939887.012546] ata9: hard resetting link May 2 10:29:31 serveur kernel: [939897.009232] ata9: softreset failed (device not ready) May 2 10:29:41 serveur kernel: [939907.005909] ata9: hard resetting link May 2 10:29:52 serveur kernel: [939917.561817] ata9: link is slow to respond, please be patient (ready=0) May 2 10:30:17 serveur kernel: [939941.996512] ata9: softreset failed (device not ready) May 2 10:30:17 serveur kernel: [939941.996527] ata9: limiting SATA link speed to 3.0 Gbps May 2 10:30:22 serveur kernel: [939947.176649] ata9: reset failed, giving up May 2 10:30:22 serveur kernel: [939947.176658] ata9.00: disabled May 2 10:30:22 serveur kernel: [939947.176665] ata9.00: device reported invalid CHS sector 0 May 2 10:30:22 serveur kernel: [939947.176689] ata9: EH complete May 2 10:30:22 serveur kernel: [939947.176728] sd 8:0:0:0: [sdh] Unhandled error code May 2 10:30:22 serveur kernel: [939947.176732] sd 8:0:0:0: [sdh] May 2 10:30:22 serveur kernel: [939947.176735] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK May 2 10:30:22 serveur kernel: [939947.176739] sd 8:0:0:0: [sdh] CDB: May 2 10:30:22 serveur kernel: [939947.176741] Read(16): 88 00 00 00 00 00 12 d8 ad 60 00 00 00 20 00 00 May 2 10:30:22 serveur kernel: [939947.176759] end_request: I/O error, dev sdh, sector 316190048 May 2 10:30:22 serveur kernel: [939947.176770] BTRFS: bdev /dev/sdh errs: wr 0, rd 1, flush 0, corrupt 0, gen 0 May 2 10:30:22 serveur kernel: [939947.176799] sd 8:0:0:0: [sdh] Unhandled error code May 2 10:30:22 serveur kernel: [939947.176802] sd 8:0:0:0: [sdh] May 2 10:30:22 serveur kernel: [939947.176805] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK May 2 10:30:22 serveur kernel: [939947.176808] sd 8:0:0:0: [sdh] CDB: May 2 10:30:22 serveur kernel: [939947.176810] Read(16): 88 00 00 00 00 00 f5 eb 37 a0 00 00 00 20 00 00 May 2 10:30:22 serveur kernel: [939947.176826] end_request: I/O error, dev sdh, sector 4125833120 May 2 10:30:22 serveur kernel: [939947.176836] BTRFS: bdev /dev/sdh errs: wr 0, rd 2, flush 0, corrupt 0, gen 0 May 2 10:30:22 serveur kernel: [939947.176997] end_request: I/O error, dev sdh, sector 5756096272 May 2 10:30:22 serveur kernel: [939947.177007] BTRFS: bdev /dev/sdh errs: wr 1, rd 3, flush 0, corrupt 0, gen 0 May 2 10:30:22 serveur kernel: [939947.177023] BTRFS: bdev /dev/sdh errs: wr 2, rd 3, flush 0, corrupt 0, gen 0 May 2 10:30:22 serveur kernel: [939947.177044] BTRFS: bdev /dev/sdh errs: wr 3, rd 3, flush 0, corrupt 0, gen 0 May 2 10:30:22 serveur kernel: [939947.177057] BTRFS: bdev /dev/sdh errs: wr 4, rd 3, flush 0, corrupt 0, gen 0 May 2 10:30:22 serveur kernel: [939947.177072] BTRFS: bdev /dev/sdh errs: wr 5, rd 3, flush 0, corrupt 0, gen 0 May 2 10:30:22 serveur kernel: [939947.177086] BTRFS: bdev /dev/sdh errs: wr 6, rd 3, flush 0, corrupt 0, gen 0 May 2 10:30:22 serveur kernel: [939947.177100] BTRFS: bdev /dev/sdh errs: wr 7, rd 3, flush 0, corrupt 0, gen 0 |
Tous les malheurs de la terre semblent s’abattre sur le disque dur sdh. Curieusement, le monitoring SMART n’a pas pu anticiper la panne comme c’est le cas parfois.
Je décide donc d’extraire le disque dur défectueux et d’installer son replaçant.
Retrait du disque défectueux
Voici ensuite un état des lieux qui m’informe que le devid 5 (le disque sdh) est manquant.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
root@serveur:/data# btrfs filesystem show warning devid 5 not found already Check tree block failed, want=21020672, have=0 read block failed check_tree_block Couldn't read chunk root Label: none uuid: f9355025-d7fb-41a8-8589-8682b11fa3bf Total devices 8 FS bytes used 10.91TiB devid 1 size 2.73TiB used 2.73TiB path /dev/sdi devid 2 size 2.73TiB used 2.73TiB path /dev/sde devid 3 size 2.73TiB used 2.73TiB path /dev/sdf devid 4 size 2.73TiB used 2.73TiB path /dev/sdg devid 6 size 2.73TiB used 2.73TiB path /dev/sda devid 7 size 2.73TiB used 2.73TiB path /dev/sdb devid 8 size 2.73TiB used 2.73TiB path /dev/sdc *** Some devices missing Btrfs v3.17 |
La commande qui suit est fondamentale dans le cadre de cet article : j’ai besoin de monter le système de fichiers en mode dégradé mais lecture-écriture tout de même.
1 |
root@serveur:/# mount -o degraded,rw /data |
Quelque minutes après le système de fichiers est utilisable en mode RW. On peut vérifier cela avec la commande qui suit.
1 2 3 |
root@serveur:/data# mount [...] /dev/sdi on /data type btrfs (rw,relatime,degraded,compress=zlib,space_cache) |
Ajout du disque de remplacement
Vient donc la commande de suppression de disque dur manquant. Ne l’utilisez pas tout de suite, il faut préalablement ajouter le disque de remplacement. Sans cela, vous obtiendrez probablement un échec pour cause d’espace disque insuffisant. En effet, Btrfs cherche à tout prix à conserver la redondance RAID1 en dupliquant un maximum de blocs sur les autres disques.
1 2 |
root@serveur:/# btrfs device delete missing /data ERROR: error removing the device 'missing' - No space left on device |
Il fallait en réalité commencer par ajouter le nouveau disque, pour supprimer ensuite l’ancien disque manquant.
1 |
root@serveur:/# btrfs device add /dev/sdh /data -f |
A partir de là, avec un disque libre de 2,73 TiB, le retrait du disque devient plus envisageable.
1 2 3 4 5 6 7 8 9 |
root@serveur:/data# btrfs filesystem show /data Label: none uuid: f9355025-d7fb-41a8-8589-8682b11fa3bf Total devices 9 FS bytes used 10.91TiB devid 1 size 2.73TiB used 2.73TiB path /dev/sdi [...] devid 9 size 2.73TiB used 0.00B path /dev/sdh *** Some devices missing Btrfs v3.17 |
Il m’a tout de même fallu équilibrer (balance) l’array afin que les autres disques ne soient pas à 100% d’usage.
L’opération « balance » a encore sa part de mystère pour moi, j’ai l’impression que cela permet de répartir les données uniformément sur les disques durs d’une part, et également remplir les blocs de système de fichiers qui ne seraient pas remplis à 100% par des fichiers. La plupart du temps, on ne veut pas équilibrer tout à l’aveugle (explications ici) mais on veut spécifier un seuil d’occupation du bloc en-deçà duquel on s’affranchit de bouger les donnés. Cela permet de rendre le système de fichiers « plus compact ».
L’opération prend plusieurs heures. Avec l’outil atop on voit qu’elle semble solliciter tous les disques en écriture principalement, à des vitesses de l’ordre de 5 Mo/sec par disque. Btrfs est en train de remplir le nouveau disque avec des données existantes et à qui il manquait la redondance suite au crash disque.
1 |
root@serveur:/# btrfs balance start -dusage=50 /dat |
On peut suivre l’avancement de l’opération avec la commande suivante.
1 2 3 |
root@serveur:~# btrfs filesystem balance status /data Balance on '/data' is running 3068 out of about 11185 chunks balanced (3668 considered), 73% left |
La suppression du disque manquant ne doit plus poser de problème. Malheureusement on ne peut pas suivre l’avancement de cette suppression, simplement tenter d’équilibrer les disques pour faire de l’espace, avant.
1 |
root@serveur:/# btrfs device delete missing /data |
Ce qui est original avec Btrfs par rapport à d’autres systèmes de fichiers, c’est qu’il nécessite d’être monté, même en mode dégradé, afin d’opérer les modification sur le RAID. On ne peut pas discerner la fonctionnalité de RAID mode blocs et du système de fichiers.
Parfait , je dois justement changer un de mes deux disques 🙂
Alors bon courage, appuyez-vous sur la documentation officielle, et n’oubliez pas de tout sauvegarder préalablement au cas où !