Btrfs sur un raid10 mdadm ou raid10 btrfs sur des appareils nus?

J'ai un RAID10 géré par le mdadmet j'ai un système de fichiers EXT4 dessus. Cependant, j'aime BTRFS et je voudrais convertir le système de fichiers EXT4 en BTRFS, mais je pensais aux performances et à la maintenabilité. Pour un exemple avec BTRFS, je ne peux pas facilement voir l'état lorsque je supprime / ajoute un autre disque à la matrice comme je le peux avec mdadm (ou peut-être que je ne sais pas comment - j'ai cherché dans les documents BTRFS et je n'ai pas pu trouver cela ).

Donc, d'après votre expérience, quel est le meilleur choix:

1. Pour simplement convertir le système de fichiers EXT4 et laisser mdadm gérer le RAID10?

2. Pour se débarrasser de mdadm et laisser BTRFS faire tout?

Laissez Btrfs faire tout.

D'une part, Btrfs a son propre code de mise en miroir intégré qui peut être plus intelligent que madm.

Bien sûr, si un disque tombe en panne dans une paire en miroir dans un madm raid10, vous pouvez remplacer le mauvais disque et continuer votre vie (bien qu'après un ensemble de commandes shell extrêmement pénible). Le problème est que si votre disque tombe en panne un peu plus doucement: si quelques blocs renvoient simplement les mauvais bits au lieu de donner les codes d'erreur appropriés pour un mauvais bloc, alors lors de la lecture des données, vous obtiendrez au hasard de mauvaises données. Btrfs est plus intelligent que cela: il additionne chaque bit de données. Pour être honnête, je ne sais pas s'il est plus correct de dire «chaque nœud BTree» ou «chaque bloc», mais le fait est que lorsqu'il lit certaines données d'un tableau en miroir, il vérifie la somme de contrôle avant de la restituer à votre processus utilisateur. Si la somme de contrôle ne correspond pas, elle consulte d'abord l'autre miroir du tableau, et si cela donne la somme de contrôle correcte,

Le wiki Btrfs mentionne spécifiquement votre question :

Si Btrfs devait s'appuyer sur le mappeur de périphériques ou le MD pour la mise en miroir, il ne serait pas en mesure de résoudre les échecs de somme de contrôle en vérifiant la copie en miroir . Les couches inférieures ne connaissent pas la somme de contrôle ou la granularité des blocs du système de fichiers et ne sont donc pas en mesure de vérifier les données qu'elles renvoient.

Enfin, même sans cet avantage substantiel, le flux de travail en ligne de commande pour traiter les périphériques Btrfs supprimés ou ajoutés est super simple. Je ne suis même pas sûr de pouvoir obtenir correctement les commandes de shell dégradé pour le montage, puis la réparation de votre système de fichiers, mais pour Btrfs, il est très clairement documenté sur la page des périphériques multiples comme:

mount -o degraded /dev/sdb /mnt
btrfs device delete missing /mnt

À ce stade, si vous avez suffisamment d'espace sur vos disques restants, vous pouvez toujours juste btrfs rebalanceet en finir avec; pas besoin de remplacer le miroir, comme il faudrait absolument le faire avec du madm! Et si vous voulez le remplacer, vous pouvez le faire en btrfs device addpremier.

BTRFS est encore expérimental et vous pouvez vous retrouver avec des fonctionnalités "intéressantes" si quelque chose devait planter. Si vous avez / voulez vraiment exécuter btrfs, il serait pour l'instant beaucoup plus sûr de l'exécuter au-dessus d'un raid logiciel que de le lancer directement. Lorsque btrfs arrive à maturité et entre en production, cela peut ne plus être vrai.