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…
- Plus de 50% du disque sera utilisé pour assurer cette sécurité
- Car le raid5/6 est toujours en cours de développement
- Pas de chiffrement des données
- En cas de panne d’un disque, il est nécéssaire de démonter le FS !
- Une fragmentation importante.
- Une fiabilité encore très éloignées des FS habituels.
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
- https://btrfs.wiki.kernel.org/index.php/Main_Page
- https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices
- https://btrfs.wiki.kernel.org/index.php/Gotchas
- https://btrfs.wiki.kernel.org/index.php/FAQ
- http://richardhartmann.de/blog/posts/2012/02/RAID-sucks/
- http://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_11
Salut,
ton titre parle de fiabilité, as-tu des données là dessus autres que les vagues assertions de ton article ?
paulez
Salut,
Je ne suis pas certain de bien comprendre ta question…
Mon titre peut facilement se traduire par : « btrs est censé être fiable, mais cet avantage ne dois pas masquer un certain nombre d’inconvénients ».
Inconvénients que je crois lister assez clairement dans mon billet… Non ?
Concernant la fiabilité actuelle de btrfs, je n’ai pas d’autre éléments factuels que le contenu des pages de ce genre :
https://btrfs.wiki.kernel.org/index…
https://btrfs.wiki.kernel.org/index…
Mais elles montrent clairement que btrfs est loin d’être stabilisé.
EDIT : En fait si, ça c’est du très factuel :
https://bugs.archlinux.org/task/34039
Corrigé dans le kernel… 3.8 ! Personnellement, je suis encore en 2.6.X …
Je suis visiblement pas le seul à pas être hyper emballé :
http://www.phoronix.com/scan.php?page=news_item&px=MTExMjg
(la aussi on parle de corruptions de données)
Pourquoi entretenir un quelconque espoir dans un système de fichiers qui n’a pas encore fait ses preuves quand il existe déjà un équivalent (à peu près) ?
Je veux bien entendu parler de ZFS, qui en plus d’offrir une très bonne intégrité des données et une réplication assez facile, permet d’obtenir des performances assez intéressantes.
Je n’ai pas souvent utilisé ZFS. Par contre, j’avais beaucoup utilisé un système de fichier qui, d’un point de vue utilisation, lui ressemblait beaucoup : AdvFS. Et franchement, en terme d’usage pur, ZFS ne lui arrive pas à la cheville.
Surtout, certains des reproches que je fais à btrfs s’appliquent à ZFS. Vouloir remplacer un gestionnaire de volume, je ne suis pas certain que ce soit une bonne idée. Mais si on veut partir dans cette direction la, alors il faut le faire, mais il faut le faire bien. La dernière fois que j’ai eu des infos sur ZFS il n’était toujours pas possible de retirer un disque d’un pool ! (ouch).
Le fait que même les développeurs de ZFS reconnaissent que leur produit est fait un peu usine a gaz patchée de partout, et que sa conception interne est au final beaucoup moins « jolie » que celle de btrfs ne me met pas vraiment en confiance…
Enfin, le fait qu’il ne soit pas intégré au noyau (même si il ne s’agit que d’un problème de licence) est quand même problématique. Pouvoir rapidement retrouver ses données à partir de n’importe quel live CD sans customisation particulière est une chose importante.
Globalement, tant qu’un système de fichier ne m’apportera pas des avantages décisif (protection des données, fonctions avancées de compression et de chiffrement etc) par rapport aux FS traditionnels, je ne vois aucune raison de changer.
Re-bonjour Hoper!
Je ne suis pas tout a fait d’accord avec toi concernant le volume occupé et le fonctionnement.
Les infos que je t’ai remontées étaient issues d’une conversion ext4 => btrfs, d’où le fait de la fragmentation entre blocs data et metadata.
au final, les metadata n’occupent pas 50%, comme cela semblais être le cas au début (après un « défrag » des blocs de metadata, on tombe à environ 10.04Gb pour 18Tb de partition (et 10.9Tb de data).
donc 0.1% de metadata.
Donc je m’oppose à quelques points:
1 – le volume occupé pour la sécurité des données : 0.1%
2 – la fragmentation : fragmentation entre meta et data ne veux pas forcément dire fragmentation des datas. Ne pas oublier non plus que mon btrfs provient d’une conversion, pas une création.
3 – l’espace libre certes moins facile a comprendre qu’un simple df, il garde l’avantage de donner l’espace réel occupé par les data/meta (oui, en cas de compression activé, df donnera la taille normal, btrfs fi df donnera la taille réel occupé (donc avec compression)
Sinon oui:
1 – les fonction de raid, je m’en sers pas. je ne troquerais pas mon baril de mdadm contre deux de btrfs avant d’être grand-père 😉
2 – btrfs est toujours en développement, donc certaines fonctions sont encore pour les casses-cou. ça sera le cas pour encore de nombreuses années.
Comme tu sais, j’avais quelques choix lors de mon étude sur mon problème de taille (limitation à 16Tb sur une partition ext4 crée sur un os 32bits, information que l’on ne trouve qu’en grattant, sinon partout on parles de 16exa-octets de limitation…), et mon meilleur choix, sans faire de vases communiquant avec mes disques entre deux mdadm (donc très stressant pour les disques) à été btrfs.
Après quelques déboires, dont surtout l’incompréhension des premiers résultats du « btrfs df », qui m’indiquaient effectivement grosso-modo 4tb de meta pour 9Tb de data, au final tout se passe bien aujourd’hui, et il a survécu à la première coupure de courant provoqué par ma femme.
Je pense que ce problème est du au fait que btrfs peu dans un bloc mixer data et meta, mais lors d’un df, seul l’un des deux compte, et donc l’intégralité de ce bloc est reporté comme data ou meta.
Cordialement,
Zapan
Yop.
Je pense que n’a pas bien compris ce que j’entendais par « sécurité des données » dans ce billet.
Quand je parle de sécurité des données, je ne parle pas de réaliser un simple CRC des méta data du FS, mais bien de pouvoir retrouver une données qui n’est plus accessible à cause d’un secteur défectueux ou autre. C’est cette sécurité qui est mise en avant par btrfs. Mais, pour cela, il faut impérativement avoir plusieurs copies de la même donnée. Ce n’est pas ce que tu as fait, (puisque par défaut, sur un disque unique, il ne crée qu’une copie des données). Tu ne dispose donc pas de cette sécurité. Si tu avait crée ton FS avec l’option -d raid1 (ou un truc dans le genre) tu aurai bien deux copies de chaque données, et donc une volumétrie globale plus que divisée par deux (car il n’y a pas que les data qui prennent deux fois plus de place, mais aussi les meta datas)
Concernant la fragmentation, je suis persuadé qu’une conversion est évidement pire que de partir d’un FS fraichement crée en btrfs. Mais cela ne change rien à l’existence d’une fragmentation réelle et suffisamment handicapante pour que les développeurs aient intégré des mécanismes de défragmentation en arrière plan. Mécanismes qui, comme, tu l’a constaté, ne fonctionne pas si bien que ça puisque il existe apparemment pas mal de cas ou il faut lancer soit même à la main les « balance » qui vont bien. (CF les FAQ etc). Donc oui, c’est une préoccupation supplémentaire pour l’utilisateur. Préoccupations auxquelles les utilisateurs de systèmes unix n’étaient plus vraiment habitués.
Salutations,
effectivement btrfs souffre de sa jeunesse, j’ai personnelement testé cet fs 3 fois, les deux premières ont donné de très mauvais résultats sur une coupure de courant, la dernière s’est montré plus que convaincante, notemment sur le remplacement de disques à chaud, sur des disques sata sans raid, testé avec un noyaud 3.8.
actuellement il y as deux gros problème sur cet fs
1 – pas moyen de connaitre la taille d’un snapshot !!, même si les snapshots sont bougrements efficaces, on ne peux qu’estimer la taille de tout les snapshots, j’ai lu quelques part que ce problème sera résolu prochainement par l’utilisation des quotas…
2 – la suppression d’un disque/partition btrfs est buggé, malgré la suppression effective d’un disque/partition (remplacement par exemple) ce dernier continue d’apparaitre, il survit même à un wipefs, résultat il faut effacer la signature du fs avec un dd, ce sera surement résolut avec le kernel 3.9 .
Pourquoi btrfs ?, eh bien ext4 est certe performant mais c’est un dinosaure de l’informatique, il s’affranchis des write barrier et fait complètement confiance au disque pour les écritures, si cet option est activé sur ext4 les perfs du fs s’écroulent. Plus sérieusement btrfs tient compte des ssd, ils sont détectés automatiquement, on peut même mixer sata et ssd (mod single pour les données)
Ce n’est pas par hasard qu’oracle a encouragé son dévellopement ainsi que d’autres grandes sociétés, je trouve juste dommage qu’aucune alternative n’as été réellement trouvée pour remplacer l’option atime du fs, qui est désastreuse sur btrfs.
« Plus sérieusement btrfs tient compte des ssd »
ext4 aussi… Des options de montage spécifiques existent…
Globalement, de très bons conseils sont données ici pour utiliser les SSD en ext4 sont disponible ici :
http://doc.ubuntu-fr.org/ssd_solid_…
et la :
http://www.webupd8.org/2013/01/enab…
Ton commentaire montre en tout cas que ce FS est, comme je l’explique, loin d’être prêt. La question reste la même : Lorsque il le sera, ses avantages seront ils suffisamment décisifs pour que le commun des mortels l’utilise ? Personnellement j’en doute. Peu de gens ont besoins des snapshots. Mais tout le monde veut savoir combien il reste de place dans son FS. L’avenir nous dira si je me goure 🙂