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.
Avantages:
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 majeures 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.
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.
<note>“sous-volumes” et “snapshots” sont en fait les mêmes entités. Sauf qu'un sous-volume peut être créé vide, alors qu'un snapshot est la copie d'un autre sous-volume ou snapshot. On peut utiliser indifféremment l'un ou l'autre.</note>
Imaginons que vous ayez dans votre sous-volume @home (que vous avez monté en /home
) un Fichier1:
btrfs:snapshot-1
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: btrfs:snapshot-2
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. btrfs:snapshot-3
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/@
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 -clzo /
/etc/fstab
en ajoutant dans les options de montage compress=lzo
.btrfs-compsize
). Si ce n'est pas le cas, voici comment télécharger et compiler la dernière version:sudo apt install build-essential libbtrfs-dev
compsize-master
et lancez: make
compsize
que vous pouvez alors utiliser. Exemple: > sudo ./compsize /usr Processed 212419 files, 90023 regular extents (113050 refs), 117223 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 68% 2.8G 4.2G 4.6G none 100% 1.2G 1.2G 1.3G lzo 54% 1.5G 2.9G 3.2G
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).
Même si les outils fonctionnant au niveau bloc sont a priori plus efficaces, ils consomment beaucoup plus de CPU et de mémoire, prennent plus de temps, mais surtout sont fortement déconseillés avec certaines anciennes versions de btrfs et du noyau. La solution safe pour dédupliquer est donc (pour le moment) de faire une déduplication au niveau fichiers.
Déduplication au niveau fichiers avec jdupes
jdupes possède une option spécifique pour btrfs.
sudo apt install jdupes ulimit -n 8192 sudo jdupes -1 -r -B /
-B
pour voir les fichiers identiques, sans dédupliquer.ulimit -n
permet d'augmenter le nombre de fichier ouverts simultanément (1024 par défaut, ce qui peut être trop juste pour jdupes. Si vous n'augmentez pas à 8192, vous risquez d'avoir l'erreur “too many open files” qui va nuire à l'efficacité de la déduplication.)#!/bin/bash btrfs filesystem defragment -r /partition jdupes -1 -r -B /partition
Et un cron mensuel par exemple :
0 12 1 * * /usr/local/scripts/dedupBtrfs >/dev/null 2>&1
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.
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
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 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 peuvent être compressés (gain de place).
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.
btrfs:btrfs-migration
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=lzo
) + 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=lzo,subvol=@ 0 1 UUID=e3dc85e3-0d2b-40e3-803b-7c2cb0bf543a /home btrfs defaults,noatime,nodiratime,autodefrag,compress=lzo,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=lzo
: 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.
Si au démarrage vous avez un long message “Scanning for Btrfs filesystems…” alors que vous n'utilisez pas Btrfs, vous pouvez le désactiver:
sudo apt purge btrfs-tools sudo update-initramfs -ukall