Quel est le meilleur système de fichier RAID 1 sous Linux?

Mes stations et petits serveurs sont généralement montés avec deux disques durs en miroir (RAID1) pour les données et permettant une redondance en cas de défaillance brutale de l’un d’eux. Actuellement en format Ext4 sur du une volume RAID 1 Linux (mdadm), je veux savoir si j’ai à gagner à changer ce système de fichier. Je ne me suis intéressé qu’aux systèmes réputés très stables.

Voici donc cette petite étude faite en toute subjectivité mais où j’ai tout de même veillé à multiplier les conditions de test pour vérifier qu’il n’y ait pas trop de variabilité dans les données. Spoiler, cette étude m’a convaincu que basculer mes stations en BTRFS compressé et de lancer des tests de montée en charge en BTRFS sur des gros serveurs de 10 disques en RAID 6.

Les inconvénients du RAID 1 classique sont-ils dépassables?

Les disques en miroir ont deux inconvénients que je souhaite dépasser au moins partiellement :

  • Ils ralentissent nettement l’écriture (mais accélèrent la lecture).
  • Ils gâchent beaucoup d’espace disque car par définition les données sont dupliquées.

Les conditions du test

Ma station de test ne dispose de deux disques Western Digital modèle « Rouge » 6To pour serveurs NAS qui sont assez lents. Ils sont branchés sur une carte contrôleur SATA PCI-e. Le flux de données est donc de base assez ralenti et vous devez prendre en compte cela dans les résultats.

Sur les différents systèmes de fichiers, j’ai utilisé trois types de données de test:

  • 3 Go d’un gros fichier vidéo (MKV) non compressable.
  • 3 Go de fichiers MBOX, boites aux lettres de Thunderbird. Ce sont des gros fichiers (~100Mo) texte très facilement compressables.
  • 10Go de fichiers systèmes (mon /usr/share) de taille moyenne 19ko. Il y a des fichiers binaires et textes.

J’ai testé BTFS en miroir natif, qui est réputé très stable, mais le lecteur doit bien avoir en tête que ce système reste expérimental quand il gère du RAID 5 ou 6. Pour faire du RAID5 ou 6 en BTRFS, il vaut mieux l’utiliser sur un RAID 5 Linux (mdadm), puis formater son volume RAID en BTRFS.

Vitesse d’écriture des différents systèmes

Taille des données

Conclusions

Voici les conclusions relatives aux conditions de mon test (disques lent, bon CPU) :

  • Les systèmes de fichiers compressés ne sont pas vraiment plus lent que les systèmes natifs voire sont parfois bien plus rapides.
  • BTRFS compressé est le système le plus rapide et plus compact.  Il l’est tout autant en miroir natif (c’est lui qui gère le RAID), ou en RAID délégué à Linux (mdadm).

Les fonctionnalités bonus de BTRFS

Les instantanés (snapshots)

Avec BTRFS j’utilise les snapshots pour faire instantanément des sauvegardes de l’état de mes données et garder un historique tout en minimisant l’espace disque. La magie du Copy On Write permet ne ne stocker qu’une seule version d’un fichier, tant que celui-ci ne diffère pas de sa version archivée dans un instantané. C’est d’une simplicité déconcertante :

btrfs subvolume snapshot -r /dossier /.snapshots/date-du-jour

L’option -r rend le snapshot non modifiable.

La déduplication pour gagner encore plus d’espace disque!

J’utilise en plus l’utilitaire duperemove qui fait de la déduplication « offline » et permet d’augmenter de beaucoup le taux de compression. C’est assez impressionnant de réaliser à quel point nous stockons des données redondantes. J’obtiens facilement 5% de gain supplémentaire et dans certaines configurations j’obtiens même aux alentours de 50% sur mes archivage de données. Cet utilitaire, qui peut être lancé la nuit, va chercher les bouts de fichiers identiques pour ne les stoker qu’une fois. Je l’utilise en créant une base de donnée qui lui permet de ne pas avoir à recalculer à chaque fois les empreintes. Là aussi l’usage est très simple:

duperemove -rdh --hashfile=/dossier/hashfile.dupremove --skip-zeroes /dossier/

Enfin, pour savoir combien d’espace disque vous avez gagné l’outil compsize vous permet de calculer automatiquement cela.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.