# Btrfs

Btrfs (B-tree file system, prononcé ButterFS$^,$) est un système de fichiers des années 2010 fondé sur le Copy-On-Write (copie sur écriture en français) sous licence GNU GPL, développé conjointement par Oracle, Red Hat, Fujitsu, Intel, SUSE, STRATO AG (en) et autres. En 2012, alors qu'il n'était pas encore considéré comme tout à fait stable, un effort intense de développement et de test est fourni par la communauté afin de faire de Btrfs le successeur de ext4 et ext3, systèmes de fichiers habituels des distributions Linux. OpenSuse 13.2 propose dès son lancement Btrfs par défaut pour la partition racine afin d'assurer la sécurité et laisse le choix entre ext4 et XFS (plus rapide) pour /home.
Btrfs offre les fonctionnalités suivantes absentes d'autres systèmes de fichiers :
* instantané (snapshots) ;
* somme de contrôle.
Ces caractéristiques sont importantes pour les systèmes Linux, serveurs comme postes clients, car les tailles de stockage comme les configurations tendent à augmenter et à se complexifier.
La technique de l'instantané, en particulier, garantit de pouvoir faire une sauvegarde cohérente des fichiers du système tels qu'ils étaient au moment précis de l'instantané, même si la sauvegarde dure plusieurs heures et que de nombreux fichiers sont modifiés entre-temps.

## Histoire

La structure de données de Btrfs (copy-on-write avec un Arbre B) a été proposée par un chercheur d'IBM, Ohad Rodeh, lors d'une conférence USENIX en 2007. Chris Mason, ancien ingénieur de SUSE, rejoint Oracle fin 2007 et commence à travailler sur la conception de Btrfs basé sur la structure de données en Arbre B. La possibilité de sauvegarder les serveurs sans interrompre leurs opérations est en effet très demandée.
Red Hat a retiré la prise en charge du Btrfs depuis la version 7.4 de la RHEL, sortie le 1er août 2017. La distribution Linux CentOS 8.0 ne dispose plus d'aucun paquet dans ses dépôts permettant de prendre en charge les systèmes de fichiers Btrfs.

## Fonctionnalités
### Extent

Btrfs, comme Ext4, est basé sur la notion d'extent. C'est une zone contiguë (pouvant atteindre plusieurs centaines de Mo, à la différence des clusters de quelques Ko plus anciens) réservée chaque fois qu'un fichier est enregistré sur le disque dur. Ainsi, en cas d'écriture en fin de fichier (append) ou de réécriture complète de celui-ci, les nouvelles données vont souvent directement dans l'extent existant plutôt que dans une autre zone du disque dur. Cette utilisation de l'extent diminue la fragmentation, et donc augmente les performances sur un disque dur classique (mais n'apporte pas de gain sur un SSD). Cette efficacité en temps se paie d'une plus grande occupation d'espace disque, dont le coût a diminué de plusieurs ordres de grandeur. Btrfs stocke par ailleurs les données des très petits fichiers directement dans l'extent du fichier répertoire, et non dans un extent séparé.

### Sous-volumes et instantanés (snapshots)

Btrfs gère une notion de « sous-volumes » sous forme d'arbre séparé (y compris la racine) de répertoires et des fichiers, permettant diverses arborescences simultanément, les rendant plus indépendantes du système principal. Les données sont ainsi mieux séparées et on peut imposer différents quotas par sous-volumes. L'avantage principal est la possibilité d'instantanés (nommés également snapshots). Un instantané permet de « prendre une photographie » à un instant donné d'un système de fichiers pour le sauvegarder dans cet état cohérent tout en continuant à travailler. Cet instantané est un sous-volume, modifiable après coup. Cette modification en écriture possible en plein cours de sauvegarde (d'un état juste antérieur) permet la haute disponibilité des bases de données en ligne.

### Copy-on-write

Pour exploiter ces sous-volumes et ces instantanés, Btrfs utilise la technique classique du « copy-on-write ». Si des données sont à écrire sur un bloc mémoire, alors celui-ci est copié à un autre endroit du système de fichiers de façon à ne pas altérer l'original, et les nouvelles données seront par la suite enregistrées sur la copie. Ensuite les méta-données pointant sur le bloc sont modifiées automatiquement afin de prendre en compte les nouvelles données. Ce mécanisme transactionnel diffère de la journalisation présente dans ext3 qui mémorise juste ce qui existait avant écriture et le conservait jusqu'à confirmation que celle-ci s'étaient bien passée. Prendre un instantané du système permettrait, en cas de problème, de revenir aussitôt à l'instantané, sans avoir à rejouer le fichier des en-cours au moment de la défaillance. Outre les questions de performances (Btrfs n'a pas les performances de XFS), cela ouvre des interrogations : quand prendre un instantané pour quels volumes de données ? Le nom d'« instantané », emprunté au monde de la photographie, est trompeur dans la mesure où si l'état figé est bien celui d'un instant, l'opération prend tout de même typiquement quelques dizaines de millisecondes, même s'il est sans rapport avec les dizaines de minutes d'une sauvegarde. L'utilisation des instantanés pour cet usage n'est d'ailleurs pas un point mis en avant par les développeurs.
Elle est en revanche capitale pour les synchronisations, les archivages et les sauvegardes, garantissant que tout le système de fichiers choisi sera synchronisé, archivé ou sauvegardé sera dans un état cohérent avec ce qu'il était au début de l'opération, même si l'on continue à travailler dessus et que l'opération de sauvegarde prend plusieurs heures. Cette possibilité permet des sauvegardes cohérentes, sous condition que l'équipe informatique la mette en œuvre.

### Protection des données

Btrfs possède ses techniques propres de protection des données : l'utilisation de références arrière (back references - c'est-à-dire savoir, à partir d'un bloc de données, quelles méta-données pointent vers le bloc) permet d'identifier des corruptions du système. Si un fichier prétend appartenir à un ensemble de blocs et que ces blocs prétendent de leur côté relever d'un autre fichier, cela indique que la cohérence du système est altérée. Btrfs effectue de plus des sommes de contrôle sur toutes les données et sur les méta-données stockées afin de pouvoir détecter toutes sortes de corruptions à chaud, en réparer quelques-unes, et ainsi proposer un meilleur niveau de fiabilité.

### Redimensionnement à chaud

Il permet de redimensionner à chaud la taille du système de fichiers (y compris en le rétrécissant) tout en conservant une excellente protection des méta-données qui sont dupliquées en plusieurs endroits par sécurité. L'opération est simple : btrfs filesystem resize +2g /mnt ajoute 2 Gio à son système de fichiers. Cette fonction ne se veut pas redondante avec ce que propose le gestionnaire de volume logique de Linux mais prétend le compléter techniquement.

### Vérification du système de fichiers très rapide

La vérification du système de fichiers par l'intermédiaire du programme btrfsck est tolérante aux erreurs et présentée comme extrêmement rapide par sa conception. L'utilisation des arbres B permet d'explorer la structure du disque à une vitesse essentiellement limitée par la vitesse de lecture du disque. Le revers de la médaille est une forte empreinte mémoire puisque btrfsck utilise trois fois plus de mémoire que e2fsck.

### Couches

Btrfs respecte la hiérarchie des « couches » fonctionnelles de Linux. Par exemple, bien que proposant des fonctions le complétant, il essaye autant que possible de ne pas réécrire tout le système de gestion des volumes proposé en standard par LVM.

### Gestion de volumes logique

Btrfs permet la gestion de volumes logiques, c'est-à-dire de faire l'agrégation de plusieurs périphériques de stockage.

### RAID

Btrfs permet la mise en œuvre de plusieurs fonctionnalités RAID.

### Compression des données

Btrfs permet la compression des données stockées. Elle peut être activée au moment du montage, tout en choisissant le type de compression parmi Zstd, Zlib et LZO.
D'autres algorithmes de compression ont été ou sont envisagés :
* Snappy de Google en janvier 2012. Il permet avec les processeurs de cette décennie d’accélérer les accès aux données, de l’ordre de 10 % par rapport à des données compressées en LZO et de 15 % par rapport à des données non compressées. Cela n'aurait pas été vrai avec des processeurs plus lents, puisque les temps de compression/décompression auraient été plus importants que le temps gagné sur les accès au disque dur. Son intégration a été par la suite abandonnée au profit de LZ4.
* LZ4 encore envisagé en janvier 2017 améliore encore les performances par rapport à Snappy (de l'ordre de 20-30 %).

## Coût associé en occupation disque et lacune sur la haute disponibilité

Assurer la sécurité et la cohérence des données entraîne certes un coût, qu'il faut comparer toutefois avec :
* D'une part celui d'en avoir moins (coût de la reprise d'activité en cas de catastrophe)
* D'autre part la baisse du coût du mégaoctet sur disque dur, divisé par 1 300 000 en 29 ans selon Seagate.
Cela étant rappelé :
* plus de 50 % du disque sera utilisé essentiellement pour assurer cette sécurité et cette cohérence ;
* lors de la panne de chaque disque, il faudra démonter le système de fichier ;
* la fragmentation sera importante, ce qui peut dégrader les performances.
Le fonctionnement interne de Btrfs rend pratiquement impossible de déterminer la quantité d'espace libre : la commande « df » ne correspond en effet qu'à l'espace apparent, pas à l'espace réel pouvant être bien plus grand. Auparavant ce type de problème ne se rencontrait sous Linux qu'avec les fichiers creux (ou « troués »).