Différences

Ci-dessous, les différences entre deux révisions de la page.

--- btrfs [2019/11/18 13:07] – [Questions] sebsauvage
+++ btrfs [2023/03/20 12:52] (Version actuelle) – [Gotchas] sebsauvage
@@ Ligne 10: / Ligne 10: @@
     * 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).
+    * Avec la compression, 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.
+    * La duplication d'un fichier ou dossier existant est instantané, et n'occupe pas d'espace disque supplémentaire (non ce n'est pas de la magie).
   * Facilité d'administration:
     * Snapshots quotidiens du système (/) (pratique en cas de mise à jour ou bidouillage du système qui se passe mal).
@@ Ligne 20: / Ligne 21: @@
 Je note ici en vrac des infos utiles ou mes interrogations.
+<note>Je ne vais pas parler ici que de certaines fonctionnalités de btrfs, mais sachez qu'on peut aller beaucoup plus loin, comme faire du RAID logiciel, faire un miroir quasi-temps réel d'un disque vers une autre machine, ou encore //remplacer à chaud un disque dur sans arrêter le système// (!)</note>
@@ Ligne 35: / Ligne 38: @@
 ==== 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.
+Le Copy-on-write (ou "CoW") est une particularité bien spécifique de certains systèmes de fichiers récents comme btrfs ou ZFS.
 === Fonctionnement ===
@@ Ligne 66: / Ligne 69: @@
     * 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).
+<note>Le fait de faire une défragmentation casse les liens de déduplication. Cela n'a aucun impact sur l'intégrité des données, mais si vous aviez des fichiers dédupliqués (par exemple avec jdupes), avec la défragmentation chaque fichier se retrouve avec sa copie des données. L'occupation de l'espace disque sera donc supérieure. Il sera nécessaire de refaire une déduplication après la défragmentation pour récupérer l'espace.</note>
 === atime ===
@@ Ligne 77: / Ligne 82: @@
 === 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).
+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=always fichier1 fichier2%%''
+Exemple: ''%%cp --reflink=auto fichier1 fichier2%%''
 À la différence des hardlinks, modifier ''fichier2'' ne modifiera pas ''fichier1''.
@@ Ligne 191: / Ligne 196: @@
   * 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).
+  * Même si vous n'avez pas activé la compression dans les options de montage, vous pouvez sans problème lire et écrire les partitions btrfs contenant des données compressées.
+Il y a donc 2 endroits où vous pouvez compresser:
+  * **Dans les options de montage de la partition btrfs** (en ajoutant ''compress=...'' ou ''compress-force=...'' dans ''fstab''). Cela activera la compression des données à l'écriture.
+  * **En compressant manuellement des fichiers/répertoire** (''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:
-  * J'ai choisi d'activer la compression lzo à l'écriture sur tout le disque.
+  * <del>J'ai choisi d'activer la compression lzo à l'écriture sur tout le disque.</del> Je suis passé à la compression zstd, très performante. (Et je ne vois toujours pas d'impact sur le CPU)
   * Je ne constate aucun ralentissement, ni en lecture ni en écriture.
   * Le disque "gratte" moins qu'en ext4.
@@ Ligne 203: / Ligne 217: @@
   * Voir occupé/libre: <code>btrfs filesystem usage /</code>
-  * Compresser tous les fichiers: <code>sudo btrfs filesystem defragment -r -v -clzo /</code>
+  * Compresser tous les fichiers: <code>sudo btrfs filesystem defragment -r -v -czstd /</code>
     * 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''.
+  * Pour que les nouveaux fichiers créés soient compressés automatiquement, modifier ''/etc/fstab'' en ajoutant dans les options de montage ''compress-force=zstd''.
   * 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, [[https://github.com/kilobyte/compsize|compsize]]:
+  * Pour savoir ce que vous gagnez comme place grâce à la compression, vous pouvez utiliser ''compsize'' (''sudo apt install btrfs-compsize'').
 <hidden Cliquez pour afficher comment installer et utiliser compsize>
-  * ''sudo apt install build-essential''
+  * **Note**: //compsize// est généralement fourni dans les depôts des distributions (paquet ''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''
   * Téléchargez et dézippez https://github.com/kilobyte/compsize/archive/master.zip
   * Entrez dans le répertoire ''compsize-master'' et lancez: ''make''
@@ Ligne 239: / Ligne 255: @@
 \\
+==== Comment lire un compte-rendu de compsize ====
+<code>Type       Perc     Disk Usage   Uncompressed Referenced
+TOTAL       65%      1.4G         2.1G         4.0G  </code>
+  * Ce dossier contient 4 Go de données.
+  * Certains fichiers (dans différents sous-répertoires) ont un contenu identique. Avec la déduplication, il n'y a donc que 2,1 Go de données uniques dans ce répertoire.
+  * Avec la compression, ces 2,1 Go se compressent en 1,4 Go.
+  * Donc ce dossier contenant 4 Go de fichiers n'occupe que 1,4 Go sur disque.
 ----
 ===== 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
+Contrairement à ZFS, 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.
@@ Ligne 249: / Ligne 275: @@
 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.
+<note>La déduplication au niveau blocs est en théorie plus efficace, mais j'ai constaté de bien meilleurs résultats avec //jdupes// (déduplication au niveau fichiers) qu'avec //duperemove// (déduplication au niveau blocs). Je ne me l'explique pas. Donc de manière générale, parmis les solutions proposées, préférez //jdupes//.</note>
 Voici différents outils:
-<hidden Déduplication au niveau fichiers avec jdupes ⇐ :-) **solution recommandée**>
+<hidden Déduplication au niveau fichiers avec jdupes ⇐ :-) **solution recommandée** >
 jdupes possède une option spécifique pour btrfs.
 <code>sudo apt install jdupes
-ulimit -n 8192
+ulimit -n 600000
-sudo jdupes -1 -r -B /</code>
+sudo jdupes -1 -r -B /home
-  * **-1** : Rester sur un même système de fichiers.
+sudo jdupes -1 -r -B /bin /etc /lib /lib64 /opt /sbin /usr /snap /var</code>
+  * **-1** : Ne comparer que les fichiers qui sont sur le même système de fichier (btrfs ne pourra pas dédupliquer des fichiers situés dans des systèmes de fichiers différents).
   * **-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.)
+  * 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, vous risquez d'avoir l'erreur "too many open files" qui va nuire à l'efficacité de la déduplication.)
 </hidden>
+<hidden Déduplication au niveau blocs avec duperemove>
+  * Installation: ''sudo apt install duperemove''
+  * Utilisation: ''%%sudo duperemove -drh --hashfile=/.duperemove.dat /etc /lib /lib32 /lib64 /libx32 /sbin /snap /srv /usr /var /home %%''
+    * **-r** : traiter les sous-répertoires
+    * **-d** : soumettre les déduplications de blos de données à btrfs.
+    * **-h** : affichage des tailles lisible (k/M/G)
+    * **%%--hashfile=/.duperemove.dat%%** : Stocker la table de travail (hash) entre les lancements.
+    * Le premier lancement sera **long**, car il va faire la checksum de //tous// les fichiers du disque.
+    * Les lancements suivants seront nettement plus rapides, car il n'ira examiner que les fichiers nouveaux/modifiés.
+    * Le fichier ''.duperemove.dat'' lui permet de mémoriser les hashs de blocs de données et la liste des fichiers entre chaque lancement.
+    * À la fin de chaque exécution, duperemove vous affichera le gain potentiel de place gagnée par la déduplication.
+</hidden>
 <hidden Déduplication au niveau fichiers avec rmlint>
@@ Ligne 282: / Ligne 326: @@
 </hidden>
-<hidden 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.
-</hidden>
 <hidden Déduplication au niveau blocs avec bees>
@@ Ligne 300: / Ligne 335: @@
   * **Installation**:
     * Récupérer et dézipper https://github.com/Zygo/bees/archive/master.zip
-    * ''sudo apt install build-essential btrfs-tools uuid-dev markdown''
+    * ''sudo apt install build-essential uuid-dev markdown libbtrfs-dev''
     * ''make''
     * ''sudo make install''
@@ Ligne 333: / Ligne 368: @@
 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 [[https://engineering.fb.com/open-source/linux/|massivement]] btrfs sur ses serveurs. Je ne pense pas qu'ils soient très fan de la corruption de données.
+Facebook utilise [[https://engineering.fb.com/open-source/linux/|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 [[https://9to5linux.com/fedora-33-beta-released-with-btrfs-by-default-gnome-3-38-and-linux-5-8|btrfs par défaut]].
-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
@@ Ligne 363: / Ligne 396: @@
     * 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.
   * [[https://btrfs.wiki.kernel.org/index.php/Status|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.
+  * <del>Ne pas utiliser btrfs sur des **périphériques USB** (disque dur externe, clés USB...). La cause n'est pas vraiment btrfs lui-même mais la qualité désastreuse des pilotes USB.</del>  Cette recommandation a disparu du wiki officiel de btfs, je présume donc que l'utilisation de btrfs sur périphériques USB ne pose plus problème.
   * 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 ''@'').
@@ Ligne 375: / Ligne 406: @@
-===== Migration et utilisation dans Linux (Mint) =====
+===== Migration et utilisation dans Linux (Ubuntu / Linux Mint) =====
-Le noyau Linux (et Linux Mint) supporte nativement btrfs. Avantages:
+Le noyau Linux (et Ubuntu/Linux Mint) supporte nativement btrfs. Avantages:
-  * Linux Mint permet d'utiliser btrfs dès l'installation.
+  * 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).
+    * (Dans Ubuntu, //timeshift// peut être installé manuellement)
+  * En cas de problème, je peux booter sur la clé USB 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).
+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.
 ----
@@ Ligne 388: / Ligne 420: @@
 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.
+<note warning>Il est fortement déconseillé d'utiliser l'outils de migration ext4➡btrfs. Il faut mieux: sortir les fichiers sur un autre support, reformater en btrfs, puis recopier les fichiers. Vous pouvez vous aider de //fsarchiver// est extrêmement efficace pour stocker temporairement des fichiers sur un support externe.</note>
 ==== Partitionnement ====
@@ Ligne 408: / Ligne 442: @@
   - Sauvegarde du contenu de ma partition VeraCrypt avec fsarchiver (en ajoutant l'option ''-c -'' pour chiffrer l'archive)
   - Repartionnement en btrfs et ré-installation de l'OS.
-  - Activation des options de montage des volumes btrfs dans ''/etc/fstab'' (''noatime,nodiratime,autodefrag,compress=lzo'') + reboot pour prise en compte.
+  - Activation des options de montage des volumes btrfs dans ''/etc/fstab'' (''noatime,nodiratime,autodefrag,compress-force=zstd'') + reboot pour prise en compte.
   - Recopie des données du dd externe vers la machine (''fsarchiver restdir'')
   - (plus tard) Déduplication des données.
@@ Ligne 436: / Ligne 470: @@
 Je monte mes sous-volumes btrfs avec ces options:
-<code>UUID=e3dc85e3-0d2b-40e3-803b-7c2cb0bf543a /               btrfs   defaults,noatime,nodiratime,autodefrag,compress=lzo,subvol=@ 0       1
+<code>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=lzo,subvol=@home 0       2</code>
+UUID=e3dc85e3-0d2b-40e3-803b-7c2cb0bf543a /home           btrfs   defaults,noatime,nodiratime,autodefrag,compress-force=zstd,subvol=@home 0       2</code>
   * ''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.
+  * ''compress-force=zstd'' : Activer la compression à l'écriture.
   * ''autodefrag'' : Activer la défragmentation automatique.
@@ Ligne 459: / Ligne 493: @@
 ----
+===== Migration de version de Linux Mint par ré-installation =====
+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:
+  * Un sous-volume ''@'' qui sera le ''/''
+  * Un sous-volume ''@home'' qui sera le ''/home''
+  * Il ne touchera pas aux autres sous-volumes présents qu'il ne connaît pas.
+Voici comment procéder pour upgrader Mint par ré-installation sans perdre votre **@home**:
+  * Bootez sur clé USB.
+  * **Avant installation**:
+    * Dans l'explorateur de fichiers, cliquez sur votre disque dur: Vous allez voir vos sous-volume btrfs **@** et **@home**.
+    * Ouvrez un terminal dans ce dossier.
+    * Renommez-les:<code bash>sudo mv @ @.ancien
+sudo mv @home @home.ancien</code>
+    * démontez le disque.
+  * Procédez à l'installation de Linux Mint. Dans l'installeur, choisissez "Autre chose". Sélectionnez votre partition btrfs et cliquez sur le bouton "Modifier" et utilisez votre partition btrfs pour l'installation (point de montage: ''/''), **mais :!: ne cochez surtout pas la case //Formatter//**. L'installeur va ainsi créer des sous-volumes **@** et **@home** sans toucher aux sous-volumes que vous avez sauvegardés (//.ancien//). {{ :btrfs:btrfs-ubiquity-reuse.png?direct |}}
+  * À l'installation, créez l'utilisateur système avec le même nom (pour ne pas avoir à retoucher aux droits dans /home)
+  * **Après la fin de l'installation**, **:!: ne rebootez pas**.
+  * Remontez votre partition btrfs, et renommez les sous-volumes:<code bash>sudo mv @home @home.new
+sudo mv @home.ancien @home</code>
+  * Rebootez: Vous devriez avoir votre ''/home'' en l'état.
+  * Pour gagner de la place, supprimer ensuite les sous-volumes @.ancien et @home.new.
+----
 ===== Questions =====
-  * Quelle est la maintenance régulière à faire, et à quelle fréquence ? (defrag, scrub, balance... ?)
+  * Quelle est la maintenance régulière à faire sur un système btrfs, 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à).
   * 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 ?
@@ Ligne 474: / Ligne 536: @@
   * https://doc.ubuntu-fr.org/btrfs
   * http://marc.merlins.org/perso/btrfs/
+  * https://lord.re/categories/btrfs/
   * https://linuxfr.org/users/ar7
   * http://debian-facile.org/doc:systeme:btrfs
@@ Ligne 483: / Ligne 546: @@
   * 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
+----
+===== Après 7 mois sous btrfs =====
+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).
+  * **Espace libre** : J'ai beaucoup **beaucoup** plus d'espace libre qu'avant. Mais **vraiment beaucoup**. Je parle de dizaines de giga-octets gagnés sur un disque de 1 To. Grâce:
+    * Au fait que ''/'' 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.//")
+    * La compression (écriture/lecture transparente de données compressées)
+    * La déduplication (les portions de fichiers identiques sont fusionnés au niveau du stockage disque)
+  * **Accès au données** : Je n'ai constaté aucun ralentissement. La consommation CPU dûe à la compression n'est pas perceptible. Et la compression réduisant les I/O disque pour les mêmes données, je suis gagnant.
+  * **Accès aux méta-données**: btrfs est bien plus efficace qu'ext4 quand il s'agit d'accéder aux méta-données. L'indexation des fichiers et répertoires est beaucoup plus rapide. Un ''chmod -R'' sur un énorme répertoire prend une seconde en btrfs là où ext4 mettait plus de 12 secondes.
+  * N'ayant qu'un Core-i3, j'avais choisi la compression lzo (la plus rapide). La consommation CPU n'est pas perceptible. À tel point que je vais passer à la compression zstd (meilleure compression).
+  * J'ai fait attention, tel que recommandé, à désactiver le Copy-on-write sur les gros fichiers souvent modifiés (bases de données, VM). Comme ces fichiers subissent énormément de petites écritures, cela évite la fragmentation dûe au Copy-on-write.
+  * **Maintenance**: Je réalise une fois par mois (voir moins souvent) la maintenance suivante:
+    * Défragmentation (avec recompression éventuellement des blocs qui ne seraient pas compressés).
+      * (Car oui, btrfs fragmente un peu à cause du Copy-On-Write, même si c'est modéré par l'option de montage //autodefrag//)
+    * Déduplication (avec //duperemove//)
+    * Ces deux opérations me ramènent //systématiquement// un gain de place de plusieurs giga-octets, voir **plusieurs dizaines de giga-octets** (gain que je n'aurais pas en ext4).
+      * (il faut dire que Steam est partagé entre plusieurs comptes sur ma machine, et que même avec un répertoire d'installation Steam partagé, ce dernier s'épanche très largement en fichiers redondants).
+  * Je n'ai eu absolument aucun incident.
+  * J'en suis tellement content que j'ai finalement passé ma machine de travail également en btrfs. Là encore le gain de place sur disque a été phénoménal.
+    * À cette occasion, j'ai également booté sur ma clé USB pour modifier ma partition btrfs avec GParted qui l'a géré sans problème (création+déplacement+agrandissement).
+    * J'ai la tranquillité d'esprit de savoir que je peux booter sur ma clé USB pour manipuler, sauvegarder, restaurer ma partition btrfs ainsi que les snapshots qu'elle contient (il est extrêmement facile de passer d'un snapshot à l'autre depuis la clé USB, ou même d'aller chercher un fichier précis dans un ancien snapshot).
+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:
+  * C'est un gain de performances pour les disques durs traditionnels.
+  * C'est un gain de durée de vie pour les SSD puisque cela réduit les écritures.
+Histoire de vous donner un ordre d'idée, sur ma machine de travail:
+  * Mon système (''/'') 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.
+  * Le ''/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:
+  * **Swap** : Dans les versions récentes, btrfs supporte un fichier de swap, mais je n'ai pas pris le temps d'essayer. J'ai mis une petite partition de swap. Mais qui n'est jamais utilisée car:
+    * J'ai activé zram (''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**.
+  * Comme les SSD n'aiment pas les écritures, quelques moyens de réduire les écritures:
+    * Mettre ''/tmp'' et ''/var/tmp'' en ram avec tmpfs.
+      * Ces répertoires ne contiennent pas beaucoup de données, mais subissent des écritures très fréquentes.
+      * à ceux qui me diraient "//il ne faut pas mettre /var/tmp en RAM//", je dirais que tout le monde dit qu'il ne faut pas, mais sans apporter de raison solide. J'ai Googlé, je n'en ai trouvé aucune concrète à part des pages qui disent "il ne faut pas". Cela fait des mois que je tourne avec /var/tmp en tmpfs, et aucun problème à signaler.
+    * Passer le //swappiness// à 10 au lieu de 60.
+    * Vous pouvez aussi regarder du côté de log2ram pour réduire la fréquence des écritures dans /var/log.