Outils pour utilisateurs

Outils du site


btrfs

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
btrfs [2020/01/20 09:42]
sebsauvage [Questions]
btrfs [2020/06/24 14:06] (Version actuelle)
sebsauvage [Partitionnement]
Ligne 10: Ligne 10:
     * Meilleure gestion des petits fichiers qu'ext4.     * Meilleure gestion des petits fichiers qu'ext4.
   * Meilleures performances:   * 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.     * 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).     * 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. 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).   * 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).   * 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: 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.   * Je ne constate aucun ralentissement, ni en lecture ni en écriture.
   * Le disque "gratte" moins qu'en ext4.   * Le disque "gratte" moins qu'en ext4.
Ligne 204: Ligne 214:
  
   * Voir occupé/libre: <code>btrfs filesystem usage /</code>   * 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):     * 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//       * Avant compression: //Used: 9.03 GiB / Free (estimated) : 29.06 GiB//
       * Après compression: //Used: 5.04 GiB / Free (estimated) : 33.11 GiB//       * Après compression: //Used: 5.04 GiB / Free (estimated) : 33.11 GiB//
       * On gagne 4 Go d'un coup !       * 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 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 s'effectue au niveau blocs et pas au niveau fichiers.
   * La compression est parfaitement compatible avec les snapshots et la déduplication.   * 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.   * 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//.   * 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> <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).  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: 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.  jdupes possède une option spécifique pour btrfs. 
Ligne 286: Ligne 308:
 </hidden> </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> <hidden Déduplication au niveau blocs avec bees>
  
Ligne 371: Ligne 384:
   * [[https://btrfs.wiki.kernel.org/index.php/Status|Certaines fonctions]] de btrfs ne sont **pas stables**. Ne les utilisez pas.   * [[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.   * 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 ''@'').   * 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 377: 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.)   * 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 410: Ligne 424:
   - Sauvegarde du contenu de ma partition VeraCrypt avec fsarchiver (en ajoutant l'option ''-c -'' pour chiffrer l'archive)   - 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.   - 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'')   - Recopie des données du dd externe vers la machine (''fsarchiver restdir'')
   - (plus tard) Déduplication des données.   - (plus tard) Déduplication des données.
Ligne 438: Ligne 452:
  
 Je monte mes sous-volumes btrfs avec ces options: 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.   * ''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.   * ''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.   * ''autodefrag'' : Activer la défragmentation automatique.
  
Ligne 508: Ligne 522:
   * https://chrisirwin.ca/posts/btrfs-presentation/   * 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   * 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.
btrfs.1579513328.txt.gz · Dernière modification: 2020/01/20 09:42 de sebsauvage