btrfs est un système de fichiers moderne, bien plus avancé qu'ext4. btrfs est examiné ici dans le cadre d'une utilisation sur un ordinateur personnel.
J'ai migré ma machine personnelle d'ext4 vers btrfs, aussi bien pour le système (/) que pour mon /home. Avantages:
PS: Je ne me sers pas des fonctionnalités de btrfs (snapshot distants, etc.) pour faire mes backups. Je me sers d'un autre outils (BorgBackup).
Je note ici en vrac des infos utiles ou mes interrogations.
Il faut voir btrfs comme un énorme gestionnaire de blocs de données (de tailles variables, jusqu'à 128 ko par défaut) gérés par un arbre binaire (d'où le nom de btrfs : “Binary Tree”) permettant une recherche très rapide de ces blocs. Un fichier est décrit comme l'enchaînement d'un nombre de blocs de données. Cette particularité permet à btrfs un certain nombre de choses assez cools, comme les snapshots, la répartitions sur plusieurs supports de stockage (RAID) ou le “CoW” (Copy-on-Write).
Je ne vais pas vous énumérer ici toutes les autres particularités de btrfs (support des très gros fichiers, gestion des volumes logiques, checksum des blocs de données et méta-données, indexation des répertoires, possibilité d'envoyer les snapshot sur une autre machine, etc.). Pour cela, je vous laisser regarder le Wiki officiel.
Je ne vais ici aborder que les particularités majeurs de btrfs : Le Copy-on-Write (CoW) et les snapshots.
Le Copy-on-write (ou “CoW”) est une particularité bien spécifique de certains systèmes de fichiers récents comme btrfs ou XFS.
Avec le CoW (actif par défaut dans btrfs), toute modification d'un fichier écrit les données modifiées à côté du fichier original. Ce mécanisme permet d'assurer l'intégrité des données à tout moment. Imaginons que nous ayons un fichier constitué de blocs de données A, B, C et D:
Maintenant on écrit de nouvelles données dans une partie du fichier:
La plupart des systèmes de fichiers vont écrire les données de E par dessus C, sur place.
Avec le Copy-on-Write, btrfs va copier ces nouvelles données dans une nouvelle zone (un “extend”) et une fois la copie terminée, il va mettre à jour les méta-données du fichier pour dire que cette partie du fichier pointe sur le nouvel extend.
Ainsi, il ne peut pas y avoir d'état où les données de E sont à moitié écrites dans le fichier. Votre fichier est forcément dans un état correct: Soit dans son ancienne version (A,B,C,D) soit dans la nouvelle (A,B,E,D).
Le bloc C sera ultérieurement libéré automatiquement par un processus en tâche de fond de btrfs.
Inconvénient: Plus un fichier est modifié, plus cela génère de fragmentation.
Il y a trois manières de lutter contre cette fragmentation:
autodefrag
pour une défragmentation automatique.sudo btrfs filesystem defragment -r /
sudo chattr +C fichier
atime est probablement l'une des plus mauvaises inventions d'Unix/Linux. Il enregistre la date de dernier accès à un fichier ou un répertoire. Ce qui veut dire que tout fichier lu va générer une écriture disque.
Dans la plupart des systèmes récents, l'option de montage relatime
est active par défaut et permet de limiter ces écritures, mais dans le cas d'un système de fichier travaillant en Copy-on-Write, il vaut mieux désactiver totalement cela en utilisant les options de montage noatime
/nodiratime
dans votre /etc/fstab
.
Attention: Certains outils (serveurs de mail, certains outils de backup, audit) ont besoin de la date de dernier accès au fichier. noatime
peut donc potentiellement nuire à leur fonctionnement. D'une manière générale, sur un serveur, évitez noatime
sur /var/spool
et /tmp
. (Là dans le cadre de ma machine perso, avec aucun serveur de mail qui tourne dessus, j'ai activé noatime
partout. Quant à /tmp, il est en tmpfs (en mémoire) et non dans la partition btrfs).
Astuce: Quand vous copiez des fichiers avec cp
à l'intérieur de votre partition btrfs, ajoutez l'option --reflink=auto
: Cela va utiliser CoW. Non seulement la copie du fichier sera instantanée, mais elle ne consommera aucun espace disque supplémentaire (Bien sûr cela ne fonctionne qu'à l'intérieur d'un même système de fichiers btrfs).
Exemple: cp --reflink=auto fichier1 fichier2
À la différence des hardlinks, modifier fichier2
ne modifiera pas fichier1
.
Des données ne commenceront à être écrites sur disque que si vous modifiez l'un des deux fichiers. Avant cela, ils partagent leurs blocs de données.
L'autre truc extrêment cool avec CoW, c'est la possibilité de faire des snapshots (des “images”) instantanées de votre système de fichiers.
Imaginons que vous ayez dans votre sous-volume @home (que vous avez monté en /home
) un Fichier1:
Maintenant on créé une copie (un snapshot) de @home en @backupHome:
sudo btrfs subvolume snapshot @home @backupHome
Le snapshot est immédiat, car aucune donnée n'est copiée. On se contente de dire que dans ce nouveau snapshot @backupHome, Fichier1 pointe sur les mêmes blocs de données:
Mais que se passe-t-il quand dans @home on écrit dans Fichier1 ? Et bien avec CoW, il va créer un extend qui contient les nouvelles données, et faire pointer cette partie du fichier sur le nouveau bloc E, mais uniquement dans ce sous-volume @home.
Vous pouvez donc accéder à l'ancienne version de Fichier1 dans @backupHome, et la nouvelle dans @home, sans pour autant avoir besoin d'avoir deux copies complètes des données du fichier sur disque.
Ainsi les blocs de données partagés entre sous-volumes et snapshots n'occupent pas plus de place sur disque. Ce qui prend de la place sur disque, ce sont les modifications de données.
Encore plus cool: Vous avez besoin de revenir à l'ancienne version de votre “home” ? C'est désarmant de simplicité:
sudo mv @home @home.old sudo mv @backupHome @home
(oui, c'est aussi simple que cela !)
Bien entendu, à force d'accumuler des snapshots, cela prend de la place. Il convient de ne pas accumuler de manière inutile des snapshots sous peine de remplir son disque dur. Mais cela permet de prendre à n'importe quel moment des instantanés de votre système de fichiers, et d'y revenir très facilement en cas de problème.
Voici quelques commandes pour gérer les sous-volumes et snapshots:
sudo btrfs subvolume list /
ID 257 gen 5525 top level 5 path @ ID 258 gen 5525 top level 5 path @home ID 271 gen 5434 top level 5 path timeshift-btrfs/snapshots/2019-10-28_16-47-34/@ ID 272 gen 5525 top level 5 path timeshift-btrfs/snapshots/2019-10-29_11-11-18/@
@
(montée sur /
)@home
(monté sur /home
)timeshift-btrfs/
: Les snapshots de @
créés par Timeshift.> mount | grep /dev/sda /dev/sda1 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@) /dev/sda1 on /home type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@home)
@subvol=/…
)Manipulation des volumes et snapshots:
> sudo mkdir -p /mnt/sda1 > sudo mount /dev/sda1 /mnt/sda1 > ls -l /mnt/sda1 total 0 drwxr-xr-x 1 root root 242 oct. 29 15:08 @ drwxr-xr-x 1 root root 8 oct. 29 13:24 @home drwxr-xr-x 1 root root 210 oct. 29 14:59 timeshift-btrfs
sudo btrfs subvolume list /
@
et @home
) ainsi que les snapshot Timeshift.> cd /mnt/sda1 > sudo mkdir -p snapshots
> sudo btrfs subvolume snapshot @home snapshots/@home-2019-10-29
-r
: > sudo btrfs subvolume snapshot -r @home snapshots/@home-2019-10-29
> mv @home @home.old > mv snapshots/@home-2019-10-29 @home
> sudo btrfs subvolume snapshot snapshots/@home-2019-10-29 @autreCopie
> sudo btrfs subvolume delete snapshots/@home-2019-10-29
> sudo btrfs subvolume create @kiki
> sudo btrfs subvolume show @home @home Name: @home UUID: eee8706b-7178-e14b-a567-dfe5041eac1e Parent UUID: - Received UUID: - Creation time: 2019-10-29 13:21:37 +0100 Subvolume ID: 258 Generation: 5540 Gen at creation: 10 Parent ID: 5 Top level ID: 5 Flags: - Snapshot(s): snapshots/@home-2019-10-29
> sudo btrfs filesystem du -s /mnt/sda1/timeshift-btrfs/snapshots/2019-10-30_15-38-24/@ Total Exclusive Set shared Filename 6.53GiB 100.36MiB 4.60GiB /mnt/sda1/timeshift-btrfs/snapshots/2019-10-30_15-38-24/@
Il y a donc 2 endroits où vous pouvez compresser:
compress=…
ou compress-force=…
dans fstab
). Cela activera la compression des données à l'écriture.sudo btrfs filesystem defragment -r -v -czstd /répertoire
). Vous pouvez faire cela même si l'option de compression n'est pas active dans les options de montage. btrfs saura lire et manipuler ces fichiers compressés sans problème.Mon expérience:
/
et /home
est désormais partagé, ce qui me laisse plus de place libre.Donc en ce qui me concerne, ce n'est que du positif.
btrfs filesystem usage /
sudo btrfs filesystem defragment -r -v -czstd /
/etc/fstab
en ajoutant dans les options de montage compress-force=zstd
.compsize
(sudo apt install btrfs-compsize
).
Contrairement à XFS, btrfs ne fait pas (encore) de déduplication en temps réel. Il n'est également pas fourni avec des outils officiels pour faire la déduplication. Il faut lancer des outils tiers pour dédupliquer les données. Il en existe plusieurs: https://btrfs.wiki.kernel.org/index.php/Deduplication#Dedicated_btrfs_deduplicators
Cette déduplication ne peut être effectuée que sur une partition montée.
Certains outils de déduplication fonctionnent au niveau fichier (les fichiers identiques en entier seront dédupliqués), d'autres au niveau blocs de données (les blocs de données identiques, même dans des fichiers différents, seront dédupliqués).
Voici différents outils:
On trouve beaucoup d'histoires de corruptions et de problème avec btrfs. Mais il semblerait qu'elles soient toutes liées à d'anciennes versions (<2016) de btrfs. Or le développement de btrfs est très actif. Afin d'éviter les problèmes, il est donc conseillé d'utiliser des noyaux Linux récents.
Facebook utilise massivement btrfs sur ses serveurs. Je ne pense pas qu'ils soient très fan de la corruption de données.
Les NAS de Synology utilisent aussi btrfs. La distribution Linux Fedora utilise btrfs par défaut.
Ceci dit, certaines fonctionnalités de btrfs ne sont pas considérées comme stable et ne devraient pas encore être utilisées (par exemple RAID56) : https://btrfs.wiki.kernel.org/index.php/Status
Quoi qu'il en soit, la règle suivante est toujours valable: FAITES DES BACKUPS
Je ne manquerai pas d'indiquer dans cette page si j'ai des soucis avec btrfs.
On trouve des avis contradictoires.
En performances pures, ext4 semble meilleur que btrfs, mais je n'ai jamais vu de comparaison avec un btrfs compressé lzo (données compressées, donc en moins d'I/O disque, donc en principe plus rapide).
df
ne donnera pas la place libre exacte). Des esprits brillants se sont penchés sur le problème, et il n'existe pas de manière totalement fiable d'effectuer ce calcul à l'heure actuelle.btrfs filesystem usage /
vous donnera sans doute des résultats plus précis que df
.autodefrag
.chattr +C …
) sur les gros fichiers qui sont modifiés souvent (bases de données, machines virtuelles, conteneurs docker)noatime
/nodiratime
sudo btrfs filesystem defragment -r /
)commit
par défaut en ext4 est généralement de 5 secondes. btrfs a un commit
par défaut de 30 secondes.@
monté en /
, @home
monté en /home
, faire un snapshot de @
ne fera pas un snapshot de @home
. Le répertoire /home
apparaîtra comme un répertoire vide dans le snapshot de @
).Le noyau Linux (et Ubuntu/Linux Mint) supporte nativement btrfs. Avantages:
L'énorme avantage des snapshots systèmes Timeshift en btrfs, par rapport à ext4, c'est qu'ils sont instantanés (ça prend moins d'une seconde) et qu'ils prennent moins de place que les snapshots rsync.
Il existe un outils de migration ext4 vers btrfs, mais il n'est absolument pas stable. J'ai donc choisi de déplacer temporairement mes fichiers sur un disque externe, reformater, et re-transférer les fichiers.
Notes:
/
dans un @rootfs
au lieu de la racine btrfs @
. J'envisage éventuellement ça par la suite, mais pour le moment je laisse tel quel.Planning de la migration:
sudo fsarchiver -v -Z 1 savedir /mnt/sdb1/home.fsa /home
savedir
=sauvegarder un répertoire, -v
pour verbose, -Z 1
pour utiliser la compression ztsd (très rapide).-c -
pour chiffrer l'archive)/etc/fstab
(noatime,nodiratime,autodefrag,compress-force=zstd
) + reboot pour prise en compte. fsarchiver restdir
)À l'installation de Mint:
Après installation:
/etc/fstab
:UUID=e3dc85e3-0d2b-40e3-803b-7c2cb0bf543a / btrfs defaults,subvol=@ 0 1 UUID=e3dc85e3-0d2b-40e3-803b-7c2cb0bf543a /home btrfs defaults,subvol=@home 0 2
/
est monté depuis la racine btrfs @
./home
est monté depuis le sous-volume @home
de btrfs.
L'installeur de Linux Mint met automatiquement /home
dans un sous-volume btrfs @home
ce qui est une excellente idée. Cela permet de faire des snapshots séparés du système et des fichiers utilisateurs. (On peut donc par exemple restaurer un snapshot du système (@
) sans impacter les données des utilisateurs (@home
) ; C'est d'ailleurs ce que vous proposera Timeshift).
Je monte mes sous-volumes btrfs avec ces options:
UUID=e3dc85e3-0d2b-40e3-803b-7c2cb0bf543a / btrfs defaults,noatime,nodiratime,autodefrag,compress-force=zstd,subvol=@ 0 1 UUID=e3dc85e3-0d2b-40e3-803b-7c2cb0bf543a /home btrfs defaults,noatime,nodiratime,autodefrag,compress-force=zstd,subvol=@home 0 2
noatime
: Ne pas enregistrer la date de dernier accès aux fichiers.nodiratime
: Ne pas enregistrer la date de dernier accès aux répertoires.compress-force=zstd
: Activer la compression à l'écriture.autodefrag
: Activer la défragmentation automatique.Linux Mint est fourni avec Timeshift et encourage fortement à son utilisation.
Par défaut, Timeshift fera un backup automatisé du système (tout sauf /home) en utilisant btrfs. C'est une excellente idée, et permet de revenir en arrière en cas de mise à jour ou bidouillage du système qui pose problème, sans que cela impact les données utilisateur.
Timeshift utilisant les fonctionnalités btrfs, les snapshots sont instantanés.
Timeshit a une GUI pour simplifier la configuration automatisée des snapshots et permet aussi de les consulter facilement.
Quand je change de version de Linux Mint/Ubuntu, je procède par ré-installation. Cependant, même si Linux Mint supporte btrfs, l'installeur de Mint (Ubiquity) ne permet pas de spécifier des sous-volumes précis pour l'installation.
L'installeur Ubiquity supporte malgré tout btrfs, et créé automatiquement dans la partition btrfs:
@
qui sera le /
@home
qui sera le /home
Voici comment procéder pour upgrader Mint par ré-installation sans perdre votre @home:
sudo mv @ @.ancien sudo mv @home @home.ancien
/
), mais sudo mv @home @home.new sudo mv @home.ancien @home
/home
en l'état.sfill -fllvz /
n'est pertinent ? Par quoi remplacer ? (il y a des outils internes btrfs ?). Ou c'est juste impossible ?Voici donc un petit bilan après avoir passé ma machine personnelle d'ext4 en btrfs il y a 7 mois (j'ai migré en novembre 2019, nous sommes en juin 2020).
/
et /home
partagent l'espace libre (fini de me dire “aannn j'ai besoin de 20 Go en plus dans /home que je n'ai pas. Il y a 30 Go libres dans ma partition système, mais je ne peux pas l'utiliser.”)chmod -R
sur un énorme répertoire prend une seconde en btrfs là où ext4 mettait plus de 12 secondes.Alors c'est un gros oui. Je continue sous btrfs. Je gagne énormément de la place, je réduis les I/O disque, et j'ai des outils de snapshot extrêmement pratiques.
Comme avec la compression la quantité globales de données écrites et lues sur disque est moindre:
Histoire de vous donner un ordre d'idée, sur ma machine de travail:
/
) fait 10 Go, mais il n'occupe que 5,8 Go sur disque grâce à la compression. C'est un gain net de 4,2 Go./home
contient 427 Go de données, mais n'occupe que 314 Go sur disque. C'est un gain de 113 Go sans effort.
PS: Puisqu'on me pose des questions:
sudo apt install zram-config
et rebootez. Constatez l'utilisation du swap zram par rapport au swap disque avec un cat /proc/swaps
). Résultat: Cela fait bien longtemps que je n'ai plus eu d'écriture dans le swap disque, même sur ma machine qui n'avait que 4 Go de RAM. Je vous recommande chaudement l'activation de zram, même si vous avez beaucoup de RAM. Dans la pratique, cela élimine les écritures dans le swap disque./tmp
et /var/tmp
en ram avec tmpfs.