Btrfs—abréviation de « B-Tree File System » et fréquemment prononcé « butter » ou « butter eff ess »—est le système de fichiers le plus avancé présent dans le noyau Linux principal. À certains égards, btrfs cherche simplement à supplanter ext4, le système de fichiers par défaut pour la plupart des distributions Linux. Mais btrfs vise également à fournir des fonctionnalités de nouvelle génération qui brisent le moule simple du « système de fichiers », en combinant les fonctionnalités d’un gestionnaire de matrice RAID, d’un gestionnaire de volume, etc.

Nous avons de bonnes et de mauvaises nouvelles à ce sujet. Premièrement, btrfs est un remplacement ext4 à disque unique parfaitement cromulent. Mais si vous espérez remplacer ZFS – ou une pile plus complexe basée sur une gestion RAID discrète, une gestion de volume et un système de fichiers simple – le tableau n’est pas si rose. Bien que le projet btrfs ait résolu bon nombre des problèmes flagrants avec lesquels il a été lancé en 2009, d’autres problèmes restent essentiellement inchangés 12 ans plus tard.

Histoire

Chris Mason est le développeur fondateur de btrfs, sur lequel il a commencé à travailler en 2007 alors qu’il travaillait chez Oracle. Cela amène de nombreuses personnes à croire que btrfs est un projet Oracle, ce n’est pas le cas. Le projet appartenait à Mason, pas à son employeur, et il reste un projet communautaire non grevé par la propriété d’entreprise à ce jour. En 2009, btrfs 1.0 a été accepté dans le noyau Linux principal 2.6.29.

Bien que btrfs soit entré en ligne principale en 2009, il n’était pas réellement prêt pour la production. Au cours des quatre prochaines années, la création d’un système de fichiers btrfs afficherait le message délibérément effrayant suivant à l’administrateur qui a osé mkfs une btrfs, et cela nécessitait une valeur par défaut Y procéder:

Btrfs is a new filesystem with extents, writable snapshotting,
support for multiple devices and many more features.

Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET
FINALIZED. You should say N here unless you are interested in
testing Btrfs with non-critical data.

Les utilisateurs de Linux étant des utilisateurs de Linux, beaucoup ont choisi d’ignorer cet avertissement et, sans surprise, de nombreuses données ont été perdues. Cette version bêta de quatre ans a peut-être eu un impact durable sur la communauté des développeurs de btrfs, qui, d’après mon expérience, avait tendance à se rabattre sur « eh bien, tout est bêta de toute façon » chaque fois que des problèmes signalés par les utilisateurs survenaient. Cela se passait bien après mkfs.btrfs a perdu son dialogue effrayant à la fin de 2013.

Cela fait maintenant près de huit ans que la balise « expérimentale » a été supprimée, mais de nombreux problèmes séculaires de btrfs restent sans réponse et restent inchangés. Donc, nous allons répéter ceci une fois de plus: uneun système de fichiers à disque unique, btrfs est stable et pour la plupart performant depuis des années. Mais plus vous approfondissez les nouvelles fonctionnalités offertes par btrfs, plus le sol sur lequel vous marchez est instable, c’est ce sur quoi nous nous concentrons aujourd’hui.

Caractéristiques

Btrfs n’a qu’un seul véritable concurrent dans l’espace des systèmes de fichiers Linux et BSD : OpenZFS. Il est presque impossible d’éviter de comparer et d’opposer btrfs à OpenZFS, car le diagramme de Venn de leurs ensembles de fonctionnalités respectifs n’est guère plus qu’un simple cercle légèrement grumeleux. Mais nous allons essayer d’éviter autant que possible de comparer et d’opposer directement les deux. Si vous êtes un administrateur OpenZFS, vous le savez déjà ; et si vous n’êtes pas un administrateur OpenZFS, ils ne sont pas vraiment utiles.

En plus d’être un simple système de fichiers à disque unique, btrfs propose des topologies de disques multiples (RAID), un stockage géré en volume (cf., Linux Logical Volume Manager), des snapshots atomiques de copie sur écriture, une réplication incrémentielle asynchrone, une guérison automatique des données corrompues, et compression sur disque.

Comparaison avec le stockage hérité

Si vous vouliez créer un système sans btrfs ni ZFS avec des fonctionnalités similaires, vous auriez besoin d’une pile de couches discrètes – mdraid en bas pour RAID, LVM ensuite pour les instantanés, puis un système de fichiers tel que ext4 ou xfs sur le dessus de votre coupe glacée de stockage.

Malheureusement, une pile de stockage mdraid + LVM + ext4 finit toujours par manquer certaines des fonctionnalités théoriquement les plus convaincantes de btrfs. LVM propose des instantanés atomiques mais pas de réplication directe d’instantanés. Ni ext4 ni xfs n’offrent de compression en ligne. Et bien mdraid pouvez offrir la guérison des données si vous activez le dm-integrity cible, ça craint un peu.

Les dm-integrity cible par défaut à un extrêmement faible crc32 algorithme de hachage sujet aux collisions, il nécessite d’écraser complètement les périphériques cibles lors de l’initialisation, et il aussi nécessite la réécriture complète de chaque bloc d’un disque remplacé après une panne, au-delà de l’écriture complète du disque nécessaire lors de l’initialisation.

En bref, vous ne pouvez vraiment pas répliquer l’ensemble des fonctionnalités promises de btrfs sur une pile de stockage héritée. Pour obtenir le bundle complet, vous avez besoin de btrfs ou de ZFS.

Topologies multidisques Btrfs

Maintenant que nous avons vu où les choses tournent mal avec une pile de stockage héritée, il est temps de jeter un œil à l’endroit où btrfs lui-même tombe en panne. Pour cela, le premier endroit que nous allons regarder est dans les topologies de disques multiples de btrfs.

Btrfs propose cinq topologies de disques multiples : btrfs-raid0, btrfs-raid1, btrfs-raid10, btrfs-raid5, et btrfs-raid6. Bien que la documentation ait tendance à se référer à ces topologies plus simplement, par exemple, tout comme raid1 plutôt que btrfs-raid1— nous vous recommandons fortement de garder le préfixe à l’esprit. Ces topologies peuvent dans certains cas être extrêmement différentes de leurs homologues classiques.

Comme vous pouvez le voir dans le tableau ci-dessus, btrfs-raid1 différait assez radicalement de son analogue conventionnel. Pour comprendre comment, réfléchissons à une collection hypothétique de disques « mutt » de tailles incompatibles. Si nous avons un disque 8T, trois disques 4T et un disque 2T, il est difficile d’en faire une matrice RAID conventionnelle utile. Par exemple, un RAID5 ou RAID6 devrait les traiter tous comme des disques 2T (ne produisant que 8T de stockage brut avant parité).

Cependant, btrfs-raid1 offre une prémisse très intéressante. Comme il n’associe pas réellement les disques par paires, il peut utiliser l’ensemble de la collection de disques sans gaspillage. Chaque fois qu’un bloc est écrit dans le btrfs-raid1, il est écrit à l’identique sur deux disques distincts—tout deux disques séparés. Comme il n’y a pas d’appariements fixes, btrfs-raid1 est libre de remplir simplement tous les disques au même taux approximatif proportionnel à leur capacité libre.

Les btrfs-raid5 et btrfs-raid6 les topologies sont quelque peu similaires à btrfs-raid1 en ce sens, contrairement à leurs homologues conventionnels, ils sont capables de gérer des tailles de disques incompatibles en modifiant dynamiquement la largeur des bandes à mesure que les disques plus petits se remplissent. Ni btrfs-raid5 ni btrfs-raid6 devrait être utilisé en production, cependant, pour des raisons que nous aborderons sous peu.

Les btrfs-raid10 et btrfs-raid0 Les topologies sont beaucoup plus proches de leurs homologues classiques et, dans la plupart des cas, elles peuvent être considérées comme des remplacements directs partageant les mêmes forces et faiblesses.