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.

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:

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

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:

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

• La compression se fait par extend (par blocs de données). Elle peut être active sur certains fichiers et pas d'autres.
• Vous pouvez compresser des fichiers et répertoires:
  • à la demande, avec une ligne de commande.
  • à l'écriture (option de montage à ajouter): Tout fichier écrit sera automatiquement compressé.
• Quel que soit votre choix, btrfs décompresse de manière transparente. (Vous n'avez pas besoin d'activer l'option de compression dans les options de montage pour lire les fichiers compressés).
• Il existe 3 algorithmes de compression : lzo (le plus rapide, impacte minimal sur le CPU), zstd et zlib (plus puissant, mais beaucoup plus gourmand en CPU).

Mon expérience:

• J'ai choisi d'activer la compression lzo à l'écriture sur tout le disque.
• Je ne constate aucun ralentissement, ni en lecture ni en écriture.
• Le disque "gratte" moins qu'en ext4.
• Je suis passé de 60 Go de libre (en ext4) à 242 Go de libre (sur une partition de 1 To).
• L'espace libre dans / 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.

• 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:

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:

sudo apt install jdupes
ulimit -n 8192
sudo jdupes -1 -r -B /

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

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

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

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

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:

• 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 est 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:

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

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.

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

• https://btrfs.wiki.kernel.org/
• https://computingforgeeks.com/working-with-btrfs-filesystem-in-linux/
• https://doc.ubuntu-fr.org/btrfs
• http://marc.merlins.org/perso/btrfs/
• https://linuxfr.org/users/ar7
• http://debian-facile.org/doc:systeme:btrfs
• https://www.marksei.com/getting-started-with-btrfs/
• https://www.linux.com/tutorials/how-manage-btrfs-storage-pools-subvolumes-and-snapshots-linux-part-1/
• https://www.linuxtricks.fr/wiki/systemes-de-fichiers-sous-linux-commandes-pour-gerer-ext4-xfs-et-btrfs#paragraph_btrfs
• https://en.opensuse.org/SDB:BTRFS
• https://tech.feedyourhead.at/content/btrfs-problems-with-cow
• https://chrisirwin.ca/posts/btrfs-presentation/
• https://www.unixsheikh.com/articles/battle-testing-data-integrity-verification-with-zfs-btrfs-and-mdadm-dm-integrity.html#myths-and-misunderstandings