Journal [Btrfs et openSUSE] Épisode 3 : un peu de maintenance

Posté par . Licence CC by-sa
Tags :
32
25
août
2017

Sommaire

Btrfs is hard

« Btrfs et openSUSE » est une série de journaux sur le système de fichiers Btrfs, basée sur ma propre expérience d’utilisateur d’openSUSE. Au menu :

  • des généralités sur Btrfs  ;
  • des noms qui pètent : sous‐volumes, snapshots, rollbacks  ;
  • du snapper  ;
  • du grub  ;
  • de la mise à jour incrémentale ;
  • des quotas ;
  • de la maintenance ;
  • des trucs spécifiques à openSUSE ;
  • des tentatives désespérées pour rester applicable à d’autres distributions ;
  • des erreurs (pas taper) ;
  • des bogues ;
  • des cris ;
  • des larmes ;
  • et bien plus ! Ou bien moins.

Aujourd’hui, l’épisode 3 : un peu de maintenance.

Surveiller son espace disque

df or not df ?

Surveiller son espace disque, c’est important, en particulier si l’on utilise snapper pour la première fois.

Un truc surprenant avec Btrfs, c’est que la commande df donne des valeurs assez approximatives.

Voyez l'exemple suivant :

~# df -h /
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda2           41G     17G   24G  41% /
~# btrfs filesystem df /
Data, single: total=18.81GiB, used=14.67GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=460.75MiB
GlobalReserve, single: total=512.00MiB, used=0.00B
~#

df m’indique que 17 Gio de ma partition racine sont utilisés.

btrfs filesystem df m’indique, lui, un truc complètement différent. Et incompréhensible. Mais qu’est‐ce que c’est que ça ?

Essayons de décomposer l’information :

  1. il y a plusieurs lignes, qui semblent représenter chacune l’espace utilisé par un type de données : Data, System, Metadata et GlobalReserve ;
  2. un type semble être soit single, soit DUP ;
  3. ensuite il y a :
    • une taille totale : bizarre, même en faisant leur somme, on n’arrive pas à la taille de la partition (40 Gio)…
    • une taille utilisée.

Types de blocs

blocs

Data, System, Metadata et GlobalReserve représentent en fait des groupes de blocs différents :

  • Data : les données, les vraies ;
  • Metadata : les données à propos des données ; par exemple, les noms de fichiers, les permissions, les sommes de contrôle, etc. ;
  • GlobalReserve est un espace interne d’urgence. Il est utilisé par exemple quand le système de fichiers est plein. Sa taille totale est basée sur la taille du système de fichiers et ne dépasse pas les 512 Mio ;
  • System : je ne sais pas ce que c’est. C’est petit en tout cas.

Méthodes d’allocation

single et DUP sont en fait deux sortes de niveaux de RAID. Si si, en plus de raid0, raid1, raid5, raid6 et raid10.

  • single :
    • chaque donnée n’est stockée qu’une fois,
    • c’est la valeur par défaut pour les « vraies » données (type Data) ;
  • DUP :
    • chaque donnée est stockée deux fois sur le même disque,
    • c’est la valeur par défaut pour les métadonnées (type Metadata) quand il n’y a qu’un seul disque,
    • les données (type Data) ne peuvent être au niveau DUP,
    • cela ressemble à du RAID 1, ça protège contre les erreurs au niveau bloc mais ne fournit aucune garantie si le périphérique crashe.

Je parle de ça uniquement parce que c’est utilisé pour estimer l’espace disque libre. En effet, selon le niveau de RAID, il faut appliquer un facteur correctif sur l’information renvoyée par btrfs filesystem df. Si.

Pour single c’est × 1 (la donnée n’est présente qu’une fois) ; pour DUP c’est × 2 (la donnée est présente deux fois). Pour les autres niveaux de RAID, c’est plus compliqué.

Si vous voulez en savoir plus sur le RAID avec Btrfs, il y a des informations sur le wiki de Btrfs ainsi que dans le manuel de mkfs.btrfs.

Taille totale… vraiment totale ?

La taille mentionnée est seulement la taille allouée. En effet, Btrfs n’utilise pas directement toute la taille disponible du système de fichiers (pool) ; il alloue progressivement de l’espace en fonction de ses besoins.

Bref, au total ça fait combien ?

1.21 gigowatt!

Eh bien, cela fait :

  14,67 Gio ×     1    +  16 Kio  ×   2   +  460,75 Mio  ×   2   +       0 o       ×     1    = 15,57 Gio
  `-------´   `------´ | `------´   `---´ | `----------´   `---´ | `-------------´   `------´
    data       single  |  system     DUP  |   metadata      DUP  |  GlobalReserve     single

Un total de 15,57 Gio, ce qui est différent des 17 Gio donnés par df.

Mais pourquoi est‐ce si compliqué ‽

C’est une bonne question.

Quelle que soit la réponse, c’est si compliqué que les développeurs de Btrfs se sont dit qu’il fallait offrir une autre commande. Cette commande, la voici :

~# btrfs filesystem usage /
Overall:
    Device size:              40.00GiB
    Device allocated:         20.88GiB
    Device unallocated:       19.13GiB
    Device missing:           0.00B
    Used:                     15.57GiB
    Free (estimated):         23.27GiB  (min: 13.71GiB)
    Data ratio:               1.00
    Metadata ratio:           2.00
    Global reserve:           512.00MiB (used: 0.00B)

Data,single: Size:18.81GiB, Used:14.67GiB
   /dev/sda2      18.81GiB

Metadata,DUP: Size:1.00GiB, Used:460.75MiB
   /dev/sda2       2.00GiB

System,DUP: Size:32.00MiB, Used:16.00KiB
   /dev/sda2      64.00MiB

Unallocated:
   /dev/sda2      19.13GiB

C’est plus long, certes, mais plus clair ! En effet, il y a une section Overall qui résume tout et qui applique les facteurs correctifs tout seul. 😉 On retrouve bien notre taille de 15,57 Gio !

On a quand même un truc bizarre : une grosse différence entre l’espace libre estimé (23,27 Gio) et l’espace libre minimal (13,71 Gio). Cela vient des métadonnées :

  • actuellement j’ai 460,75 Mio × 2 = 921,5 Mio de métadonnées pour 14,67 Gio de données, soit un ratio métadonnées/données d’environ 6 % (je ne sais pas si c’est beaucoup) ;
  • si jamais on écrit plein de petits fichiers, le pourcentage de métadonnées va augmenter et on va manquer de place plus tôt, car les métadonnées sont dupliquées ;
  • si jamais on écrit de gros fichiers, le pourcentage de métadonnées ne sera pas énorme et on va se rapprocher de la limite théorique.

Une explication sur ce message posté sur reddit.

Quelle taille prennent mes instantanés ?

À ma connaissance, le moyen le plus efficace pour connaître la taille d’un instantané, et plus généralement d’un sous‐volume, est de passer par les quotas Btrfs (qui seront dans un prochain épisode).

En attendant, vous pouvez utiliser btrfs filesystem du (qui est lent, car il compte) :

~# btrfs filesystem du -s /.snapshots/31/snapshot/
     Total   Exclusive  Set shared  Filename
   2.19GiB   634.02MiB     1.57GiB  /.snapshots/31/snapshot/
~#

Pour moi, la taille intéressante est la colonne Exclusive, qui représente la taille des données qui n’est pas partagée avec d’autres sous‐volumes. Set shared représente la taille des données partagées avec d’autres sous‐volumes. Puis le Total, la somme des deux.

btrfsmaintenance, la boîte à outils pour maintenir un système de fichiers Btrfs

Sur openSUSE, les outils du projet btrfsmaintenance (GPL v2.0) sont installés par défaut.

Il s’agit d’une collection de scripts pouvant être automatisés avec cron :

~$ ls /etc/cron.{month,week}ly
/etc/cron.monthly:
btrfs-scrub

/etc/cron.weekly:
btrfs-balance  btrfs-trim
~$

J’ai vu que des paquets étaient disponibles pour Arch Linux, Fedora (Copr), Gentoo. Chez Debian, le paquet est en cours de préparation (deb#813901).

Les scripts appellent des commandes classiques de btrfsprogs. Voyons lesquelles.

Équilibrage : btrfs balance

balance

Cela permet de répartir les données sur les disques.

~# btrfs balance start
btrfs balance start: too few arguments
usage: btrfs balance start [options] <path>

    Balance chunks across the devices

    Balance and/or convert (change allocation profile of) chunks that
    passed all filters in a comma-separated list of filters for a
    particular chunk type.  If filter list is not given balance all
    chunks of that type.  In case none of the -d, -m or -s options is
    given balance all chunks in a filesystem. This is potentially
    long operation and the user is warned before this start, with
    a delay to stop it.

    -d[filters]    act on data chunks
    -m[filters]    act on metadata chunks
    -s[filters]    act on system chunks (only under -f)
    -v             be verbose
    -f             force reducing of metadata integrity
    --full-balance do not print warning and do not delay start
    --background|--bg
                   run the balance as a background process
~#

Cela est utile pour :

  • répartir les données à l’ajout d’un nouveau périphérique ;
  • sur un système de fichiers avec des réplications endommagés (genre RAID 1 avec disque endommagé et enlevé), cela force le système de fichiers à reconstruire les copies sur les disques actifs ;
  • sur un système de fichiers avec un seul disque, cela permet de diminuer l’espace alloué.

Les filtres sont obligatoires si l’on ne veut pas que l’équilibrage dure une éternité. Par exemple, btrfs balance start -dusage=30 -musage=30 ne déplacera que les données et les métadonnées des groupes de blocs qui ne sont utilisés qu’à moins de 30 %.

Le script fourni dans btrfsmaintenance effectue plusieurs passes avec ce genre de filtre :

  • d’abord avec un -dusage=0 -musage=0 pour nettoyer les groupes de blocs complètement vides ;
  • puis avec des valeurs prises dans un fichier de configuration, typiquement : 1, 5, 10, 20… sans dépasser les 50.

Vérification des sommes de contrôle : btrfs scrub

Le scrub consiste à lire tous les blocs de données et de métadonnées et à vérifier leurs sommes de contrôle. Une réparation automatique est faite s’il existe une copie valide.

La syntaxe :

~# btrfs scrub start
btrfs scrub start: too few arguments
usage: btrfs scrub start [-BdqrRf] [-c ioprio_class -n ioprio_classdata] <path>|<device>

    Start a new scrub. If a scrub is already running, the new one fails.

    -B     do not background
    -d     stats per device (-B only)
    -q     be quiet
    -r     read only mode
    -R     raw print mode, print full data instead of summary
    -c     set ioprio class (see ionice(1) manpage)
    -n     set ioprio classdata (see ionice(1) manpage)
    -f     force starting new scrub even if a scrub is already running
           this is useful when scrub stats record file is damaged
~#

La tâche cron de btrfsmaintenance est appelée tous les mois.

Note : il n’y a pas de somme de contrôle pour les fichiers, dossiers et sous‐volumes pour lesquels le CoW est désactivé. Le scrub ne peut rien faire pour eux.

Défragmentation : btrfs filesystem defragment

J’ai noté que la défragmentation est un sujet qui intéresse, donc je vais détailler un peu plus en essayant de ne pas trop dire de bêtises.

Qu’est‐ce que c’est au juste ?

La défragmentation « consiste à regrouper les fragments de fichiers éparpillés sur le disque dur afin d’optimiser les temps d’accès du disque dur lors de la lecture de fichiers de taille importante ».

Est‐ce que Btrfs fragmente ?

La réponse est : oui.

Est‐ce que Btrfs fragmente beaucoup ? La réponse est : ça dépend.

La fragmentation des fichiers dépend de la façon dont les applications écrivent ces fichiers sur le disque. Donc, cela dépend des applications qui tournent. Par exemple, les bases de données – ne serait‐ce que les bases de données SQLite de Firefox – ont tendance à beaucoup fragmenter avec Btrfs, du fait que le CoW n’est pas adapté à leur fonctionnement.

Pour les fichiers qui sont complètement réécrits, il n’y a pas de fragmentation.

Vous pouvez utiliser la commande filefrag pour évaluer la fragmentation :

~# filefrag /var/log/zypper.log
/var/log/zypper.log: 66 extents found
~#

Essayons de vérifier tout le système. Cherchons les fichiers fragmentés à plus de 100 extents :

~# cat checkfrag.sh
#!/bin/bash
# Inspiré de https://gist.github.com/kylemanna/b5cac22b6164b14aa967

# Chemin des sous‐volumes / systèmes de fichiers à analyser
subvols=${2:-/ $(btrfs subvolume list / | grep -v snapshots | sed 's/@//' | awk '{ print "/"$9 }')}

# Seuil d’extents en dessous duquel les fichiers sont ignorés
min=${1:-100}

# Un petit find
find ${subvols} -xdev -type f -exec filefrag '{}' \+ | awk "{ if ( \$(NF-2) > $min ) print \$0 }"

~# ./checkfrag.sh
/var/log/alternatives.log: 225 extents found
/var/log/journal/016627c3c4784cd4812d4b7e96a34226/user-1001.journal: 164 extents found
/var/log/cups/access_log: 185 extents found
/var/log/YaST2/mkinitrd.log: 305 extents found
/var/log/audit/audit.log.4: 1472 extents found
/var/log/audit/audit.log.3: 1607 extents found
/var/log/audit/audit.log.2: 1804 extents found
/var/log/audit/audit.log.1: 1597 extents found
/var/log/audit/audit.log: 106 extents found
/var/log/wpa_supplicant.log: 269 extents found
/var/log/zypper.log-20170214: 108 extents found
/var/tmp/build-root/openSUSE_Tumbleweed-x86_64/var/lib/rpm/Packages: 1777 extents found
/var/tmp/build-root/openSUSE_Tumbleweed-x86_64/var/lib/rpm/Basenames: 501 extents found
/var/tmp/build-root/openSUSE_Leap_42.2-x86_64/var/lib/rpm/Basenames: 128 extents found
/var/tmp/build-root/openSUSE_Leap_42.3-x86_64/var/lib/rpm/Basenames: 124 extents found
/var/cache/man/index.db: 146 extents found
~#

On voit :

  • surtout des journaux ;
  • la base de données des pages man ;
  • des bases de données RPM : c’est très particulier à ma machine, ce sont des chroots que j’utilise pour construire des paquets avec osc. Vous noterez que la base de données RPM du système (dans /var/lib/rpm/) n’est pas mentionnée. On va y revenir.

Dans l’ensemble, ça va, sachant que ce système n’a pas vraiment été défragmenté depuis 2015… Bon, après, je n’ai pas de base de données qui tourne et j’ai une partition en XFS pour le /home.

Est‐ce qu’il faut défragmenter un disque dur classique avec Btrfs ?

La réponse est : oui, si nécessaire (c’te non‐réponse !).

Cela peut améliorer significativement les performance, si tant est qu’il y ait fragmentation. Voir question précédente (c’te double non‐réponse 😋).

Est‐ce qu’il faut défragmenter un SSD avec Btrfs ?

yoda

La réponse est : cela peut être utile (😃).

C’est vrai que les effets de la fragmentation se ressentent avant tout sur les disques durs classiques.

Il est vrai que pour les SSD, l’usage est de ne pas défragmenter. L’idée derrière cela est que les SSD ont des vitesses d’accès tellement rapides que la fragmentation du système de fichiers est négligeable. Il semble alors pertinent d’éviter les opérations de défragmentation, coûteuses en termes de cycles d’écriture. Surtout que ces machins‐là se montrent parfois fragiles (dixit un ex‐propriétaire d’un Kingston à la durée de vie de libellule).

Cependant, sur un SSD, une fragmentation massive (genre plus de 10 000 extents) entraînera tout de même des pics de consommation du processeur, pouvant atteindre plusieurs secondes, ce qui n’est pas souhaitable. Je suppose que c’est parce qu’il doit quand même y avoir du calcul pour résoudre tous ces fragments et que le processeur n’a pas le temps de se reposer sur le disque, vu que le SSD est très rapide.

Du coup, la défragmentation de fichiers très fragmentés est pertinente même pour un SSD.

Est‐ce que btrfsmaintenance défragmente ?

La réponse est : pas par défaut, mais il en est capable.

C’est donc à nous de jouer en réglant la configuration de btrfsmaintenance ou en utilisant directement la commande :

~# btrfs filesystem defragment
btrfs filesystem defragment: too few arguments
usage: btrfs filesystem defragment [options] <file>|<dir> [<file>|<dir>...]

    Defragment a file or a directory

    -v             be verbose
    -r             defragment files recursively
    -c[zlib,lzo]   compress the file while defragmenting
    -f             flush data to disk immediately after defragmenting
    -s start       defragment only from byte onward
    -l len         defragment only up to len bytes
    -t size        target extent size hint (default: 32M)
~#

Exemple :

~# filefrag /var/log/zypper.log
/var/log/zypper.log: 66 extents found
~# btrfs filesystem defragment -f /var/log/zypper.log
~# filefrag /var/log/zypper.log
/var/log/zypper.log: 1 extent found
~#

Pour lancer sur tout le disque, c’est : btrfs filesystem defragment -r /. Après, vous pouvez aussi adapter le script écrit plus haut pour ne défragmenter que les fichiers très fragmentés :

~# files=$(checkfrag.sh 3000 | cut -f1 -d ":")
~# [ -n files ] && btrfs filesystem defragment ${files} || echo "0 fragmented file found"
0 fragmented file found
~#

Sur openSUSE

openSUSE

On l’a vu dans l’épisode 1 : openSUSE désactive le CoW pour certains sous‐volumes, notamment ceux des bases de données MySQL et MariaDB, ainsi que ceux des machines virtuelles. Donc, cela nous évite de gérer la fragmentation de ces fichiers.

De plus, par défaut, le /home n’est pas en Btrfs : c’est une partition séparée en XFS. Cela évite d’avoir à gérer la fragmentation de toutes les bases de données utilisateurs (Firefox, Chromium, Thunderbird, Digikam…). Ce n’est sans doute pas la seule raison à ce choix, mais je pense que c’en est une valable.

Enfin, une défragmentation de la base de données RPM est faite après chaque installation de paquet via un hook de libzypp. Résultat :

~# filefrag /var/lib/rpm/*
/var/lib/rpm/alternatives: FIBMAP unsupported
/var/lib/rpm/Basenames: 1 extent found
/var/lib/rpm/Conflictname: 1 extent found
/var/lib/rpm/Dirnames: 1 extent found
/var/lib/rpm/Enhancename: 1 extent found
/var/lib/rpm/Filetriggername: 1 extent found
/var/lib/rpm/Group: 1 extent found
/var/lib/rpm/Installtid: 1 extent found
/var/lib/rpm/Name: 1 extent found
/var/lib/rpm/Obsoletename: 1 extent found
/var/lib/rpm/Packages: 2 extents found
/var/lib/rpm/Providename: 1 extent found
/var/lib/rpm/Recommendname: 1 extent found
/var/lib/rpm/Requirename: 1 extent found
/var/lib/rpm/Sha1header: 1 extent found
/var/lib/rpm/Sigmd5: 1 extent found
/var/lib/rpm/Suggestname: 2 extents found
/var/lib/rpm/Supplementname: 1 extent found
/var/lib/rpm/Transfiletriggername: 1 extent found
/var/lib/rpm/Triggername: 1 extent found
~#

Pour les SSD : fstrim

btrfsmaintenance inclut également un script qui appelle fstrim, dont l’exécution est planifiée toutes les semaines. Il est considéré comme préférable de faire des fstrim périodiquement ainsi, plutôt que de monter le système de fichiers avec l’option discard.

That’s all folks!

Liens

Sur le wiki Btrfs :

Ailleurs :

  • # Merci pour ces éclaircissements !

    Posté par (page perso) . Évalué à 5.

    Hello,

    Merci beaucoup pour ces journaux, ça m'aide mieux à comprendre pourquoi certains outils standards ne fonctionnent pas comme attendu. Ils vulgarisent très bien les principes de BTRFS et ses principaux outils.

    OpenSuse semble aussi faire une intégration très cohérente, il faut que je teste leur système :)

    • [^] # Re: Merci pour ces éclaircissements !

      Posté par . Évalué à 6.

      +1, super série de journaux.

      Par contre, devoir "éclaircir" le principe d'un FS, et devoir "intégrer" un FS dans une distrib en dit long sur la complexité de ce dernier. C'est franchement pas trivial, peut-être parce que c'est un FS qui fait le café (et le thé). Pas vraiment KISS, du coup, donc difficile à utiliser / combiner avec d'autres choses.

    • [^] # Re: Merci pour ces éclaircissements !

      Posté par (page perso) . Évalué à 4.

      Pareil, avec cette petite remarque en plus : si btrfs à l'air d'approcher un état utilisable, il semble que le chemin soit encore long avant qu'il ne soit plus un outil de spécialiste. Pour ce faire, il faudrait qu'il puisse s'utiliser avec la même facilité que la plupart des autres fs.

  • # Le point de vue de Suse sur btrfs

    Posté par . Évalué à 10.

  • # Extent et fragmentation

    Posté par . Évalué à 2.

    Tout d'abord, merci pour cette série passionnante !
    Concernant la fragmentation, je peux me tromper, mais si j'en crois la fiche Wikipédia de Btrfs, elle devrait être relativement réduite, hors changements très fréquents ou conséquents.
    En effet, on y lit qu'à l'instar d'ext4, Btrfs crée automatiquement un extent pour tout nouveau fichier, directement à sa suite : ainsi, les modifications éventuelles dudit fichier sont placées de préférence directement à ses côtés, ce qui limite la fragmentation…
    Il ne me semble pas avoir vu cet argument dans les discussions précédentes… sinon, désolé :P

  • # CPU, SSD et scheduling ?

    Posté par . Évalué à 3.

    Je suppose que c'est parce qu'il doit quand même y avoir du calcul pour résoudre tous ces fragments et que le CPU n'a pas le temps de se reposer sur le disque, vu que le SSD est très rapide.

    Si je comprends bien le sous-entendu de cette phrase : du fait des temps d'accès d'un HDD, le CPU peut sans problème passer à un autre processus, en attendant d'avoir la réponse à sa demande, alors que face à un SSD, le CPU se retrouve à switcher de processus pour revenir très vite à celui qui avait nécessité la demande au SSD ? Ou c'est encore tout autre chose ?

    • [^] # Re: CPU, SSD et scheduling ?

      Posté par . Évalué à 3.

      Si je comprends bien le sous-entendu de cette phrase : du fait des temps d'accès d'un HDD, le CPU peut sans problème passer à un autre processus, en attendant d'avoir la réponse à sa demande, alors que face à un SSD, le CPU se retrouve à switcher de processus pour revenir très vite à celui qui avait nécessité la demande au SSD ?

      Oui, enfin c'est ce que je me suis dit. Après ce n'est qu'une supposition hein, autrement je ne vois pas comment expliquer cette consommation du CPU.

  • # Correction "btrfs balance"

    Posté par (page perso) . Évalué à 3.

    Article très intéressant, un grand merci.

    Je me permets de signaler que la commande btrfs balance start -dusage 30 -musage 30 s'écrit en fait btrfs balance start -dusage=30 -musage=30.

  • # Coquille checkrag.sh

    Posté par . Évalué à 2.

    Arg, je n'ai pas copié-collé la bonne version pour le petit script checkfrag.sh. La bonne version est celle-là :

    #!/bin/sh
    
    #
    # Inspiré de https://gist.github.com/kylemanna/b5cac22b6164b14aa967
    #
    
    # Seuil d'extents en dessous duquel les fichiers ne sont pas affichés
    min=${1:-100}
    
    # Chemin des sous-volumes à analyser
    subvols=${2:-/ $(btrfs subvolume list / | grep -v snapshots | awk '{ print "/"$9 }')}
    
    # Voilà
    find ${subvols} -xdev -type f -exec filefrag '{}' \+ | awk "{ if ( \$(NF-2) > $min ) print \$0 }"

    J'ai juste inversé les arguments (optionnels) : le premier argument est le seuil, le second les chemins à analyser. Ça permet de faire le checkfrag.sh 3000 plus bas au lieu de checkfrag.sh "$chemins" 3000.

    • [^] # Re: Coquille checkrag.sh

      Posté par . Évalué à 2.

      Un grand merci aux personnes qui corrigent les coquilles. Par contre, ce serait cool de ne pas essayer de corriger plus qu'il n'en faut 😉

      ainsi que dans le manuel de [mkfs.btrfs](https://btrfs.wiki.kernel.org/index.php/Manpage/mkfs.btrfs).

      Lien cassé en voulant mettre en chasse fixe je suppose.

      Par exemple, les bases de données — ne serait‐ce que les bases de données SQLite de Firefox —

      Moi j'utilise du demi-cadratin (–), pas du cadratin (—). C'est mon droit, non ? 😋

      envoyée par btrfs filesystem df. Si !

      Il me semble bien avoir mis « Si. »…

      Bref, ça ne me dérange pas vraiment. Mais quand même 😉

  • # Btrfs et check de l'espace disponible

    Posté par . Évalué à 0.

    La taille mentionnée est seulement la taille allouée. En effet, Btrfs n’utilise pas directement toute la taille disponible du système de fichiers (pool) ; il alloue progressivement de l’espace en fonction de ses besoins.

    Les logiciels (genre df -h, gluster, ceph, nextcloud etc) sont-ils capable d'évaluer la taille disponible ou bien arrivé à un moment ces derniers vont dire, à tort que la partition est pleine? (je dis ça car j'ai 2To d'utilisé introuvable sur un jbod btrfs)

    Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.