Outils pour utilisateurs

Outils du site


btrfs

btrfs

Cette page est relativement récente: Il est possible qu'elle contienne encore quelques inexactitudes.

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:

  • Gain de place:
    • / et /home peuvent partager l'espace disponible.
    • Compression.
    • Déduplication.
    • Meilleure gestion des petits fichiers qu'ext4.
  • Meilleures performances:
    • Avec la compression lzo (extrêmement rapide), il devrait y avoir globalement moins d'I/O disque (je n'ai pas un SSD, mais un disque dur à plateaux).
    • En btrfs, les répertoires sont indexés.
  • Facilité d'administration:
    • Snapshots quotidiens du système (/) (pratique en cas de mise à jour ou bidouillage du système qui se passe mal).
    • Avant toute manipulation importante sur mes données (dans /home), au lieu de faire un backup (long), je peux faire un snapshot (instantané).

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.


Concepts de btrfs

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.

CoW (Copy-on-write)

Le Copy-on-write (ou “CoW”) est une particularité bien spécifique de certains systèmes de fichiers récents comme btrfs ou XFS.

Fonctionnement

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.

(dé)fragmentation

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:

  1. Montez votre système de fichiers avec l'option autodefrag pour une défragmentation automatique.
  2. Défragmentez manuellement des fichiers ou répertoires:
    sudo btrfs filesystem defragment -r /
  3. Pour les gros fichiers modifiés souvent (machines virtuelles, bases de données, conteneurs docker…), vous pouvez désactiver sélectivement CoW sur un fichier ou un répertoire.
    sudo chattr +C fichier
    • Notez que si vous désactivez CoW sur un répertoire, tout nouveau fichier créé dans ce répertoire aura également CoW désactivé.
    • Un fichier marqué en “NOCOW” ne pourra pas bénéficier de la compression (voir plus loin).

atime

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).

Copie de fichier rapide

Astuce: Quand vous copiez des fichiers avec cp à l'intérieur de votre partition btrfs, ajoutez l'option --reflink=always : 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=always 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.

Sous-volumes et snapshots

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.

“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.

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:

  • Lister les sous-volumes et snapshots:
    sudo btrfs subvolume list /
  • Sur un Linux Mint installé en btrfs, voici les sous-volumes créés:
    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/@
  • On retrouve:
    • La racine @ (montée sur /)
    • Le sous-volume @home (monté sur /home)
    • timeshift-btrfs/ : Les snapshots de @ créés par Timeshift.
  • Pour voir les points de montage des sous-volumes:
    > 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)
    • On voit bien le point de montage des différents sous-volumes (@subvol=/…)

Manipulation des volumes et snapshots:

  • Commencez par monter votre partition btrfs:
    > 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
  • Vous retrouvez là les sous-volumes et snapshots affichés par la commande sudo btrfs subvolume list /
  • Vous pouvez voir ici vos volumes (@ et @home) ainsi que les snapshot Timeshift.
  • Vous pouvez créer un répertoire pour stocker vos snapshots:
    > cd /mnt/sda1
    > sudo mkdir -p snapshots
  • (Libre à vous d'organiser votre arborescence de snapshots comme vous l'entendez.)
  • Ensuite:
    • Créer un snapshot :
      > sudo btrfs subvolume snapshot @home snapshots/@home-2019-10-29
    • Créer un snapshot non modifiable: ajouter -r :
      > sudo btrfs subvolume snapshot -r @home snapshots/@home-2019-10-29
    • Vous pouvez vous balader dans le snapshot: c'est un simple répertoire.
    • Restaurer votre /home depuis le snapshot:
      > mv @home @home.old
      > mv snapshots/@home-2019-10-29 @home
    • Copier un snapshot:
      > sudo btrfs subvolume snapshot snapshots/@home-2019-10-29 @autreCopie
    • Supprimer un snapshot:
      > sudo btrfs subvolume delete snapshots/@home-2019-10-29
    • Créer un volume vide:
      > sudo btrfs subvolume create @kiki
    • Si vous ne savez plus si vous avez fait des snapshots d'un volume, faites:
      > 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
      • (On voit la liste des snapshots)
  • Savoir combien de place occupe un snapshot:
    • Montez votre partition btrfs (par exemple en /mnt/sda1).
    • > 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/@
    • Exclusive : Quantité de données exclusives à ce snapshot (données qu'on ne retrouve pas dans d'autres snapshots).
    • Set shared : Quantité de données de ce snapshot communes avec d'autres snapshots.
    • ⇒ Si vous supprimez ce snapshot, vous gagnerez donc 100.36 Mo sur disque.

Compression

La compression est active sur toute ma partition.

La compression est transparente et il est possible de choisir entre trois algorithmes, variant vitesse et taux de compression: lzo (le plus rapide, impacte minimal sur le CPU), zstd et zlib (plus puissant, mais beaucoup plus gourmand en CPU). Mon choix s'est porté sur lzo.

  • Voir occupé/libre:
    btrfs filesystem usage /
  • Compresser tous les fichiers:
    sudo btrfs filesystem defragment -r -v -clzo /
    • Exemple pratique: Sur un système Linux Mint 19.2 fraîchement installé (dans une VM):
      • Avant compression: Used: 9.03 GiB / Free (estimated) : 29.06 GiB
      • Après compression: Used: 5.04 GiB / Free (estimated) : 33.11 GiB
      • On gagne 4 Go d'un coup !
  • Pour que les nouveaux fichiers créés soient compressés automatiquement, modifier /etc/fstab en ajoutant dans les options de montage compress=lzo.
  • La compression a un peu d'intelligence: Si le début d'un fichier se compresse mal, btrfs ne compressera pas le fichier (même si la compression est active dans les options). btrfs ne devrait donc pas perdre de temps à essayer de compresser les archive 7z/zip, les vidéos mp4, etc.
  • La compression s'effectue au niveau blocs et pas au niveau fichiers.
  • La compression est parfaitement compatible avec les snapshots et la déduplication.
  • Une fois un fichier compressé, on ne peut pas “décompresser” le fichier. On peut juste demander à btrfs de ne plus compresser les nouveaux extends de ce fichier.
  • Pourquoi lzo et pas zlib ou zstd ? Je n'ai qu'un Core-i3, et je veux le moins d'impact possible sur le CPU. Le but est vraiment d'utiliser un peu de CPU pour réduire les I/O disque et améliorer les performances, et non de maximiser la compression. zlib et zstd sont plus efficaces en compression que lzo, mais aussi plus gourmands en CPU.
  • La compression ne fonctionne pas pour les fichiers ou répertoires qui sont en NOCOW.
  • Pour savoir ce que vous gagnez comme place avec la compression, il faut un outils supplémentaire non fourni par défaut, compsize:

Cliquez pour afficher comment installer et utiliser compsize

Cliquez pour afficher comment installer et utiliser compsize

  • sudo apt install build-essential
  • Entrez dans le répertoire compsize-master et lancez: make
  • Cela va créer l'exécutable 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
  • none: Données non compressées ; lzo: Données compressées en lzo ; (Vous verrez aussi zstd ou zlib si vous utilisez ces algos.)
  • Colonnes:
    • Perc: Pourcentage de compression (tailles des données compressées par rapport aux données non compressées) (Plus la valeur est faible, mieux c'est)
    • Disk usage: Place effectivement occupée sur disque par ces données.
    • Uncompressed: Taille réelle des données (sans compression). Ces données peuvent être partagées entre plusieurs fichiers.
    • Referenced: Taille totale des fichiers (puisque plusieurs fichiers peuvent pointer sur les mêmes blocs de données)
  • Il y a donc au total 4,6 Go de fichiers dans ce répertoire. Avec la déduplication et la compression, ces 4,6 Go n'occupent que 2,8 Go sur disque.
  • La ligne lzo montre uniquement les fichiers qui sont compressés. Il y a 3,2 Go de fichiers qui sont dédupliqués et compressés, et qui au final n'occupent que 1,5 Go sur disque.
  • Certains fichiers n'ont pas été compressés probablement parce qu'ils ne sont pas compressibles (jpg, etc.)



Déduplication

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.

Voici différents outils:

Déduplication au niveau fichiers avec jdupes ⇐ :-) solution recommandée

Déduplication au niveau fichiers avec jdupes ⇐ :-) solution recommandée

jdupes possède une option spécifique pour btrfs.

sudo apt install jdupes
ulimit -n 8192
sudo jdupes -1 -r -B /
  • -1 : Rester sur un même système de fichiers.
  • -r : Traiter les sous-répertoires.
  • -B : Soumettre les déduplications à btrfs.
    • Astuce: Retirez le paramètre -B pour voir les fichiers identiques, sans dédupliquer.
  • jdupes va balayer les répertoires, rechercher les fichiers identiques et s'ils sont identiques octet par octet, soumettre la déduplication à btrfs.
  • La commande 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.)

Déduplication au niveau fichiers avec rmlint

Déduplication au niveau fichiers avec rmlint

rmlint possède une option spécifique pour btrfs.

  • Installez: sudo apt install rmlint
  • Lancez le scan: sudo rmlint -T df --config=sh:handler=clone /home
    • -T df pour trouver les fichiers dont le contenu est identique.
    • --config=sh:handler=clone pour que les doublons trouvés soient envoyés à btrfs pour déduplication.
  • Après le scan, il va vous afficher les doublons, et le gain potentiel. Cela va également créer deux fichiers: rmlint.sh et rmlint.json
  • Lancez rmlint.sh:
    sudo chmod +x rmlint.sh
    sudo ./rmlint.sh -d
    • Notez qu'à la fin du traitement, le script rmlint.sh se supprime lui-même.
  • Je ferais: sudo rmlint -T df --config=sh:handler=clone /bin /boot /etc /home /lib /lib64 /opt /root /sbin /usr /var

Déduplication au niveau blocs avec duperemove

Déduplication au niveau blocs avec duperemove

  • Installation: sudo apt install duperemove
  • Utilisation: sudo duperemove -dr --hashfile=/.duperemove.dat /
    • -r : traiter les sous-répertoires
    • -d : faire une déduplication btrfs
    • -h : affichage des tailles lisible (k/M/G)
    • --hashfile=/.duperemove.dat : Stocker la table de travail (hash) entre les lancements. Permet une déduplication plus efficace. Sans cela, duperemove n'utilise qu'une table en mémoire et se limite pour ne pas consommer trop de mémoire, d'où une déduplication moins efficace. Vous pouvez bien entendu mettre cette table de travail où vous voulez.

Déduplication au niveau blocs avec bees

Déduplication au niveau blocs avec bees

BEES est un déduplicateur qui travaille au niveau bloc. Notez que la déduplication se fait à la fois dans les sous-volumes et les snapshots. Donc, par exemple, il sera capable de dédupliquer un fichier qui serait également présent à l'intérieur d'un fichier tar (non compressé), ce que ne pourraient pas faire des déduplicateurs qui fonctionnent au niveau fichier entier (jdupes, rmlint).

Attention: bees ne doit pas être utilisé avec certaines versions du noyau. Voir cette page pour les versions recommandées.
  • bees est un outils en ligne de commande. Il n'y a pas de packages debian disponibles, il faut le compiler.
  • Installation:
    • sudo apt install build-essential btrfs-tools uuid-dev markdown
    • make
    • sudo make install
      • L'installation créé peu de fichiers:
        /usr/lib/bees/bees
        /usr/sbin/beesd
        /etc/bees/beesd.conf.sample
        /lib/systemd/system/beesd@.service
  • Configuration:
    • sudo cp /etc/bees/beesd.conf.sample /etc/bees/beesd.conf
    • Modifiez le fichier /etc/bees/beesd.conf:
      • UUID= : Renseignez l'UUID venant de votre /etc/fstab
      • DB_SIZE= : C'est la taille de la table de travail de bees. Elle sera stockée sur disque. Pour un disque de 1 To, avec des blocs à 128ko (par défaut dans btrfs), une table de 128 Mo est recommandée. Si la compression est activée, il est recommandé de doubler cette valeur. On va donc prendre une table de 256 Mo (1024*1024*256): DB_SIZE=$((1024*1024*256))
  • Utilisation:
    • sudo /usr/sbin/beesd <UUID>
    • Utilisez l'UUID de votre partition. Exemple: sudo /usr/sbin/beesd c6c3f724-9918-471c-8936-eb44569c4a91
  • Notes:
    • Avec bees, un service systemd est également fourni, mais je ne l'utilise pas. La déduplication est un processus gourmand en CPU, et je ne veux pas que ça se déclenche n'importe quand. Je conserve donc le lancement manuel (typiquement: le lancer une fois de temps en temps le soir, et le laisser tourner la nuit).
    • Si vous montez votre partition btrfs, vous verrez à la racine un répertoire .beeshome qui contient la fameuse table de travail de bees (256 Mo).
    • beesd étant conçu pour être un service, il ne s'arrête jamais. Vous pouvez l'arrêter à tout moment avec Ctrl+C, il reprendra là où il en était quand vous le relancerez. Pour savoir s'il a fini son travail, regardez l'occupation CPU.
    • Si vous voulez juste faire tourner beeds pendant quelques minutes, utilisez la commande timeout.
    • Et pour lui donner en prime la priorité CPU et disque minimales, utilisez nice et ionice.
    • Exemple: Lancer la déduplication pendant 15 minutes seulement, avec la priorité disque et CPU minimales:
      sudo timeout 15m nice -n 19 ionice -c3 /usr/sbin/beesd c6c3f724-9918-471c-8936-eb44569c4a91



Fiabilité

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

Quoi qu'il en soit, la règle suivante est toujours valable: FAITES DES BACKUPS :!::!::!:


Performances

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).


Gotchas

  • Quand vous effacez des fichiers, la libération des blocs de données est faite en arrière-plan. L'espace peut donc être libéré une minute plus tard (voir plus).
  • Avec btrfs, il n'existe pas de moyen de connaître vraiment combien il reste d'espace libre (donc un 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.
    • La commande btrfs filesystem usage / vous donnera sans doute des résultats plus précis que df.
  • btrfs fragmente. Conseils:
    • Montez les partitions avec l'option autodefrag.
    • Désactivez CoW (chattr +C …) sur les gros fichiers qui sont modifiés souvent (bases de données, machines virtuelles, conteneurs docker)
    • Montez vos partition avec l'option noatime/nodiratime
    • De temps en temps, défragmentez manuellement (sudo btrfs filesystem defragment -r /)
  • btrfs ne supporte pas le swap:
    • Donc utilisez une partition swap (hors de la partition btrfs) au lieu d'un fichier swap dans la partition btrfs.
  • btrfs ne supporte pas nativement le chiffrement.
    • Utilisez LUKS/dmcrypt/VeraCrypt.
  • Certaines fonctions de btrfs ne sont pas stables. Ne les utilisez pas.
  • Le commit par défaut en ext4 est généralement de 5 secondes. btrfs a un commit par défaut de 30 secondes.
  • Ne pas utiliser btrfs avec des périphériques USB (disque dur, clés USB…). La cause n'est pas vraiment btrfs lui-même mais la qualité désastreuse des pilotes USB.
  • Quand vous faites un snapshot d'un sous-volume, cela ne fait pas de snapshot des sous-volumes qui sont à l'intérieur. (Si vous avez @ 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 @).

Migration et utilisation dans Linux (Mint)

Le noyau Linux (et Linux Mint) supporte nativement btrfs. Avantages:

  • Linux Mint permet d'utiliser btrfs dès l'installation.
  • Linux Mint est fourni avec Timeshift qui prend de manière automatique des snapshots btrfs (quotidiens/hedbo/etc.)
  • En cas de problème, je peux booter sur la clé USB live Mint et accéder/réparer le système de fichiers (Je peux directement accéder aux snapshots btrfs pour restaurer).

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).


Migration depuis ext4

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.

Partitionnement

Notes:

  • Quelques personnes m'ont recommandé de mettre / dans un @rootfs au lieu de la racine btrfs @. J'envisage éventuellement ça par la suite, mais pour le moment je laisse tel quel.
  • La partition VeraCrypt sera mise dans sa propre partition, car a priori les multiples modification du fichier conteneur risquent de créer plein de données CoW pour rien (gaspillage de place et et d'I/O). Autant lui mettre sa propre partition.
  • Je n'ai pas de partition swap, j'ai 12Go de RAM et le swap est en zram seul.

Planning de la migration:

  1. Backup habituel de mon /home avec borg (parce que ceintures et bretelles)
  2. Récupération d'un HD externe 1 To temporairement (le disque de l'ordinateur à migrer fait 1 To)
  3. Formatage d'une partition en ext4 sur ce HD externe.
    • :!: Gotcha: Formattez - bien à l'avance de votre backup - votre partition de 1 To en ext4 et laissez le disque branché, car la création des inodes en tâche de fond prend une éternité. Je me suis fait avoir. J'ai perdu beaucoup de temps à cause de ça.
  4. Sauvegarde de /home sur ce disque avec fsarchiver
    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).
    • Je ne sauvegarde pas '/' car je ré-installe le système (Je change de version de Mint).
    • Pourquoi fsarchiver ? Il est fiable, très rapide, les archives sont checksummées, et surtout si une partie de l'archive est corrompue, on ne perd QUE les fichiers de la partie corrompue, pas toute l'archive. Et puis le chiffrement me permet de ne pas laisser mes données de la partition VeraCrypt en clair sur le disque externe.
  5. Sauvegarde du contenu de ma partition VeraCrypt avec fsarchiver (en ajoutant l'option -c - pour chiffrer l'archive)
  6. Repartionnement en btrfs et ré-installation de l'OS.
  7. Activation des options de montage des volumes btrfs dans /etc/fstab (noatime,nodiratime,autodefrag,compress=lzo) + reboot pour prise en compte.
  8. Recopie des données du dd externe vers la machine (fsarchiver restdir)
  9. (plus tard) Déduplication des données.

À l'installation de Mint

À l'installation de Mint:

  • Dans l'installeur, choisir le partitionnement manuel. Créer:
    • Une partition primaire btrfs, point de montage /
    • Une seconde partition primaire en ext2 (qu'on utilisera par la suite pour VeraCrypt).

Après installation:

  • Comme on peut le voir dans /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).

Options de montage

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.

Timeshift

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.


Questions

  • Quelle est la maintenance régulière à faire, et à quelle fréquence ? (defrag, scrub, balance… ?)
    • En dehors, bien sûr, de ne pas garder inutilement plein de snapshots (mais Timeshift est bien paramétrable de ce côté là).
  • Est-ce qu'il est judicieux d'utiliser btrfs à l'intérieur d'une partition VeraCrypt ?
  • Pour nettoyer l'espace libre (écrire des zéros), je présume qu'avec le CoW, un sfill -fllvz / n'est pertinent ? Par quoi remplacer ? (il y a des outils internes btrfs ?). Ou c'est juste impossible ?
  • On trouve des avis contradictoires: Est-ce que de la RAM ECC est vraiment nécessaire ? (Je dirais que non: Si vos données sont corrompues en mémoire avant d'être envoyées au système de fichier, aucun système de fichier ne les sauvera. btrfs/ZFS ne se comporteront pas pire/pas mieux dans ce cas.)
  • Je suis en train de réfléchir à ces deux solutions:
    • (1) compress=lzo dans les options de montage.
    • (2) Pas de compression dans les options de montage, mais de temps en temps un sudo btrfs filesystem defragment -r -v -czstd /
    • Je ne veux pas activer zstd dans les options de montage, car il consomme plus de CPU que lzo à l'écriture des fichiers. Donc pas bon pour du temps réel.
    • La solution 2 permettrait d'avoir un meilleur taux de compression sans bouffer de CPU (zstd compresse mieux que lzo, et consomme autant de CPU que lzo à la décompression).

Liens, sources

btrfs.txt · Dernière modification: 2019/11/08 21:38 par sebsauvage