PROJET AUTOBLOG

TDC hoper

Archivé

source: TDC hoper

⇐ retour index

btrfs : La fiabilité a un prix

mardi 30 avril 2013 à 16:34

Cela faisait très longtemps que je voulais jeter un œil à btrfs. Et après quelques jours de lecture et deux ou trois tests rapides, je suis maintenant certain de pouvoir me passer sereinement de ce FS, pendant encore de nombreuses années.

Un produit "tout en un"

La volonté de btrfs est de remplacer toutes les couches habituellement utilisées (mdadm/lvm/fs...) par un produit unique. Un "tout en un" capable, parce qu'il à justement connaissance de l'ensemble des couches, de faire plus de choses et de les faire plus rapidement qu'en utilisant des couches indépendantes (et universelles).

Malheureusement, tant que son développement n'est pas terminé, il y a au final très peu de choses dont il soit capable et qui ne soit pas déjà possible en utilisant les produits actuels. Pire, il est pour le moment moins doué dans chaque tache que le produit indépendant correspondant...

Faisons donc rapidement un petit tour d'horizon de ce qui existe déjà, de ces points forts et de ces points faibles.

De vrais avantages

L'argument fort de btrfs est de garantir la fiabilité des données. Pour cela, chaque bloc de donnée est répliqué (si possible sur plusieurs disques physique, sur le même si ce n'est pas possible) et dispose d'une somme de contrôle. A chaque lecture, on vérifie donc cette somme de contrôle, et on passe à l'autre copie du bloc en cas de soucis (puis on répare le bloc corrompu). Cela revient un peu à du raid1 si l'on dispose de deux disques (mais cela fonctionne aussi très bien avec un seul disque). A un détail près, cette réplication ne se fait pas au niveau device, mais au niveau fichier, ce qui, à l'avenir pourrait apporter d'autres avantages bien sympathiques (niveau de protection différent en fonction des répertoires ou des types de fichiers etc).

J'ai aussi beaucoup apprécié la possibilité de réaliser des snapshot au niveau fichier (cp --reflink). Très utile dans le cas de gros fichiers dont seules certaines parties évolues (images disques pour des VM etc)

Mais à quel prix !

J'ai beau être paranoïaque et placer la sécurité de mes données au dessus de toute le reste, le prix à payer dans le cas de btrfs me semble aujourd'hui trop élevé. Jugez plutôt...

Surtout, le fonctionement interne de btrfs fait qu'il est pratiquement impossible de savoir combien de place il reste. Vous avez bien lu, la commande "df" ne vous donnera aucune information utile, vous ne saurez jamais ce qu'il est encore possible ou non de copier sur votre disque, et cela n'est apparemment pas près de changer.

Voici un petit extrait de la FAQ à ce sujet :

"So, in general, it is impossible to give an accurate estimate of the amount of free space on any btrfs filesystem. Yes, this sucks. If you have a really good idea for how to make it simple for users to understand how much space they've got left, please do let us know, but also please be aware that the finest minds in btrfs development have been thinking about this problem for at least a couple of years, and we haven't found a simple solution yet."

J'ai fait le test (création d'un volume btrfs, copie de données dessus etc). Sérieusement, c'est une horreur. La commande habituelle df est totalement à l'ouest, quand à "btrfs filesystem df /point_de_montage" il faut avoir de sérieuses connaissances sur le fonctionement interne de btrfs, deux aspirines, une calculatrice et du temps devant soit (tester balancing/defrag...) pour ne serait-ce qu'estimer ce qu'il est encore possible de copier dans son volume. Je doute sincèrement que ce FS puisse être un jour utilisé par le commun des mortels. Ou alors, il s'agira d'un usage très basique (une seule copie des données etc) auquel cas pourquoi se compliquer autant la vie ? ext4 sera toujours plus adapté pour madame michu.

Conclusion

Aujourd'hui, entre un FS "nextgen" forcément bugué, en cours de développement, et auquel il faudrait pourtant confier l'intégralité de ses données (les différents FS ne seraient que des sous volumes du FS principal) et un ext4 finalement plus robuste (lui aussi toujours en développement), le choix est assez vite fait. Surtout que, grâce à LVM, on assure un vrai découpage (physique) de ses données. Dans le pire des cas, si un FS se vautre, ce n'est que ce FS la qu'il faudra restaurer (Tout le monde à bien fait des sauvegardes hein ?).

Regardez la liste des corrections récentes sur LVM, et vous aurez la preuve de la très grande fiabilité de ce système. Deux philosophies s'affrontent. L'ancienne : Chaque logiciel ne fait qu'une seule chose, mais il l'a fait bien. et la nouvelle : On fait tout, parce que cela permet de faire des choses que des briques séparées ne peuvent pas faire (déduplication, snapshot (y compris à distance) etc.

En fait, je me demande même si je passerai à btrfs lorsqu'il aura réussit à égaler puis à dépasser mdadm et lvm (en fonctionnalité ET en sécurité). Parce que le jour ou un nouvel FS arrivera, mes anciennes couches seront toujours valables. Si je m'en sépare pour passer à btrfs, je devrai tout reconstruire pour pouvoir tester/utiliser un éventuel futur FS qui n'assurerai que son rôle de système de fichier. N'oubliez pas, "le mieux est l'ennemi du bien"...

A lire