Différences

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

--- btrfs [2020/01/17 08:06] – [Questions] sebsauvage
+++ btrfs [2020/07/29 07:16] – [Migration de version de Linux Mint par ré-installation] 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).
@@ Ligne 22: / Ligne 22: @@
 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 192: / Ligne 193: @@
   * 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=...'' 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 204: / Ligne 214: @@
   * 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=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>
@@ Ligne 252: / Ligne 261: @@
 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:
-<hidden Déduplication au niveau fichiers avec jdupes ⇐ :-) **solution recommandée**>
+<hidden Déduplication au niveau blocs avec duperemove ⇐ :-) **solution recommandée**>
+  * 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 jdupes >
 jdupes possède une option spécifique pour btrfs.
@@ Ligne 263: / Ligne 285: @@
 <code>sudo apt install jdupes
 ulimit -n 8192
-sudo jdupes -1 -r -B /</code>
+sudo jdupes -r -B /home  # déduplication répertoires utilisateurs
-  * **-1** : Rester sur un même système de fichiers.
+sudo jdupes -r -B /bin /etc /lib /lib64 /opt /sbin /usr  # Déduplication côté système</code>
   * **-r** : Traiter les sous-répertoires.
   * **-B** : Soumettre les déduplications à btrfs.
@@ Ligne 286: / Ligne 308: @@
 </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 337: / Ligne 350: @@
 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.
-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 373: / Ligne 384: @@
   * [[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.
+  * 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.
   * 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 379: / Ligne 390: @@
-===== 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 412: / Ligne 424: @@
   - 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=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 440: / Ligne 452: @@
 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=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=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=zstd'' : Activer la compression à l'écriture.
   * ''autodefrag'' : Activer la défragmentation automatique.
@@ Ligne 466: / Ligne 478: @@
 ===== Migration de version de Linux Mint par ré-installation =====
-Quand je change de version de Linux Mint, je procède par ré-installation.  Cependant, même si Linux Mint supporte btrfs, l'installeur de Mint (Ubiquity) ne propose sait pas gérer les sous-volumes.
+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.
-  * Dans l'explorateur de fichiers, cliquez sur votre disque dur: Vous allez voir vos sous-volume btrfs **@** et **@home**
+  * **Avant installation**:
-  * Renommez-les:
+    * 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.
-    * <code bash>sudo mv @ @.ancien
+    * Renommez-les:<code bash>sudo mv @ @.ancien
 sudo mv @home @home.ancien</code>
     * démontez le disque.
-  * Dans l'installeur, choisissez "Autre chose" et utilisez votre partition btrfs pour l'installation, **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).
+  * 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 installation, **ne rebootez pas**.
+  * **Après la fin de l'installation**, **:!: ne rebootez pas**.
-  * Remontez votre partition btrfs, et renommez le /home:<code bash>sudo mv @home @home.new
+  * 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.
-FIXME section à finaliser.
+----
 ===== 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 510: / Ligne 527: @@
   * 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.