Btrfs
| Btrfs | |
| Développeur | Oracle Corporation |
|---|---|
| Nom anglais | Btrfs |
| Introduction | Instable : 12 juin 2007 (Linux) |
| Structure | |
| Contenu des répertoires | B-tree |
| Allocation de fichiers | extent |
| Limitations | |
| Taille maximale de fichier | 16 Eio |
| Nombre maximal de fichiers | 264 |
| Taille maximale du nom de fichiers | 255 octets |
| Taille maximale de volume | 16 Eio |
| Caractères autorisés dans les noms de fichiers | Tous excepté NUL('\0') et '/' |
| Fonctionnalités | |
| Dates enregistrées | modification (mtime), modification des attributs(ctime), accès (atime) |
| Attributs | POSIX, Attributs étendus |
| Permissions | POSIX, ACL |
| Compression intégrée | Oui (gzip, LZO[1], Snappy[2] et LZ4[3]) |
| Chiffrement intégré | Planifié |
modifier  |
|
Btrfs (B-tree file system, prononcé ButterFS[4],[5]) est un système de fichiers expérimental basé sur le Copy-On-Write (copie sous écriture en français) sous GNU GPL développé conjointement par Oracle, Red Hat, Fujitsu, Intel, SUSE, STRATO et autres [1].
Sommaire |
Histoire [modifier]
La structure de données à la base de Btrfs (copy-on-write avec B-tree[6]) a été proposé à l'origine par un chercheur de chez IBM, Ohad Rodeh lors d'une conférence USENIX en 2007[7]. Toujours en 2007 Chris Mason, un ancien ingénieur connu à l'époque pour son travail sur le système de fichier ReiserFS pour la société SUSE, rejoint Oracle en fin d'année 2007 et commence à travailler sur un nouveau système de fichiers basé sur la structure de donnée B-tree.[8]
Fonctionnalités [modifier]
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 formats plus anciens) réservée chaque fois qu'un fichier est enregistré sur le disque dur. Cela permet en cas d'écriture en fin de fichier (append) ou de réécriture complète de celui-ci, d'ajouter souvent les nouvelles données directement dans l'extent plutôt que dans une autre zone du disque dur. Cette utilisation de l'extent permet de diminuer la fragmentation, et donc d'augmenter les performances sur un disque dur classique (par opposition à un SSD). Les gros fichiers sont ainsi stockés de façon plus efficace moyennant une occupation plus importante d'espace disque, dont le coût a considérablement diminué. Btrfs stocke les données des très petits fichiers directement dans l'extent du fichier répertoire, et non dans un extent séparé.
Btrfs gère une notion de « sous-volumes » autorisant, au sein du système de fichiers, d'avoir un arbre séparé (y compris la racine) contenant des répertoires et des fichiers, donnant la possibilité d'avoir diverses arborescences simultanément, et donc une plus grande indépendance par rapport au système principal. Cela permet aussi de mieux séparer les données et d'imposer différents quotas aux différents sous-volumes. L'utilisation la plus pratique de ce système concerne les instantanés (souvent appelés par le mot anglais « snapshots »). Un instantané offre la possibilité de « prendre une photographie » à un instant donné d'un système de fichiers afin de le sauvegarder. Cet instantané sous Btrfs est un sous-volume, ce qui permet de le modifier après coup. Avoir un instantané accessible en écriture présente un intérêt évident pour les bases de données en ligne à haute disponibilité.
Pour exploiter ces sous-volumes et ces instantanés, Btrfs utilise la technique classique du « Copy-on-write ». Si des données sont écrites sur un bloc mémoire alors ce dernier sera copié à un autre endroit du système de fichiers et les nouvelles données seront enregistrées sur la copie au lieu de l'être sur l'original. Ensuite les méta-données pointant sur le bloc sont modifiées automatiquement afin de prendre en compte les nouvelles données. On a ainsi un mécanisme transactionnel distinct de la journalisation présente dans Ext3. Avant chaque écriture, prendre un instantané du système permettrait, en cas de problème, de revenir à l'instantané, mais cela semble poser, sinon des problèmes de performances, du moins des questions : faut-il prendre un instantané à chaque écriture, ou pour un certain volume de données ? Cela pose aussi la question de la perte de temps à chaque création/destruction d'instantané. L'utilisation des instantanés pour cet usage n'est d'ailleurs pas mis en avant par les développeurs.
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é.
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 : btrfsctl -r +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.
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.
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.
L'algorithme de compression léger et rapide Snappy de Google est ajouté en janvier 2012 permettant d’accélérer les accès aux données par rapport à la compression LZO (de l'ordre de 10 %) et à la non compression (de l'ordre de 15 %).
Il est suivi de l'algorithme de compression LZ4, en février 2012, qui améliore encore les performances par rapport à Snappy (de l'ordre de 20-30 %).
Notes et références [modifier]
- (en) btrfs.wiki.kernel.org
- (en) Btrfs Picks Up Snappy Compression Support sur Phoronix
- (en) LZ4 For Btrfs Arrives sur Phoronix
- (en) Valerie Henson. Chunkfs: Fast file system check and repair. “It's called Butter FS or B-tree FS, but all the cool kids say Butter FS”
- CRFS and POHMELFS [LWN.net]
- https://btrfs.wiki.kernel.org/index.php/Btrfs_design
- http://lwn.net/Articles/342892/
- https://lkml.org/lkml/2007/6/12/242
