TL; DR Les métadonnées (si le btrfs ne souffre pas de conditions générales de faible espace) augmenteront automatiquement . Dans le cas où aucun espace libre non alloué n'existe, l'augmentation automatique est hembered. Si, cependant, la partie données de btrfsa été allouée plus d'espace qu'elle n'en a besoin, il est possible de le redistribuer. Cela s'appelle balance-ing dans btrfs.
En supposant qu'il y ait suffisamment de mémoire non allouée sur le (s) périphérique (s) de support du btrfs, la partie métadonnées du système de fichiers alloue - comme le suppose l'OP - automatiquement la mémoire pour augmenter / étendre les métadonnées.
Par conséquent, la réponse est: Oui (à condition qu'il n'y ait pas de mémoire faible / d'espace libre dans le btrfs) , alors les métadonnées seront automatiquement augmentées, en tant que telles:
(1) Nous avons un aperçu de la configuration d'allocation initiale des btrfs (sur un 40GBappareil)
$> btrfs filesystem df /
Data, single: total=25.00GiB, used=24.49GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=1.55GiB, used=1.33GiB
GlobalReserve, single: total=85.41MiB, used=0.00B
(2) Comme on peut le voir, l'espace alloué dans le système de fichiers pour stocker les métadonnées est de 1,55 Go, dont 1,33 Go, donc presque tout est utilisé (cela pourrait être une situation comme dans le cas du PO)
(3) Nous provoquons maintenant une augmentation des métadonnées à ajouter. Pour ce faire, nous copions le dossier / home en utilisant l' --reflink=alwaysoption de la cpcommande.
$> cp -r --reflink=awlways /home /home.copy
(4) Depuis (comme nous supposons qu'il y avait beaucoup de fichiers dans / home), que beaucoup de nouvelles données ont été ajoutées au système de fichiers, qui, parce que nous avons utilisé, --reflinkutilise peu ou pas d'espace supplémentaire pour les données réelles, il utilise le Copie sur écriture, mécanisme. En bref, la plupart des métadonnées ont été ajoutées au système de fichiers. On peut donc avoir un autre regard
$> btrfs filesystem df /
Data, single: total=25.00GiB, used=24.65GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=2.78GiB, used=2.45GiB
GlobalReserve, single: total=85.41MiB, used=0.00B
Comme on peut le voir, l'espace alloué aux métadonnées utilisées dans ce document btrfsa automatiquement été agrandi.
Puisqu'il en est ainsi automatiquement, il n'est normalement pas détecté par l'utilisateur. Cependant, il existe certains cas, principalement ceux où l'ensemble du système de fichiers est déjà à peu près rempli. Dans ces cas, btrfspeut commencer à "bégayer" et ne parvient pas à augmenter automatiquement l'espace alloué pour les métadonnées. La raison serait, par exemple, que tout l'espace a déjà été alloué aux parties (Data, System, Metadata, GlobalReserve). De façon confuse, il se pourrait qu'il y ait encore de l'espace apparent. Un exemple serait cette sortie:
$> btrfs filesystem df /
Data, single: total=38.12GiB, used=25.01GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=1.55GiB, used=1.45GiB
GlobalReserve, single: total=85.41MiB, used=0.00B
Comme on peut le voir, le système est tout de même 40GiB, mais l'allocation est quelque peu éteinte balance, car bien qu'il y ait encore de l'espace pour les données des nouveaux fichiers, les métadonnées (comme dans le cas OP) sont faibles. L'allocation automatique de mémoire pour les périphériques supportant le btrfssystème de fichiers n'est plus possible (additionnez simplement les totaux de l'allocation, 38.12G + 1.55G + .. ~ = 40GiB).
Puisqu'il y a cependant un excès d'espace libre qui a été alloué à la datapartie du système de fichiers, il peut maintenant être utile, nécessaire pour équilibrer les btrfs. L'équilibre signifierait redistribuer l'espace déjà alloué.
Dans le cas du PO, on peut supposer que, pour une raison quelconque, un déséquilibre entre les différentes parties de l' btrfsallocation s'est produit.
Malheureusement, la commande simple sudo btrfs balance -dusage=0, qui devrait en principe rechercher des blocs vides (alloués aux données) et les mettre à un meilleur utilisateur (ce serait l'espace presque épuisé pour les métadonnées), peut échouer, car aucun bloc de données complètement vide ne peut être trouvé.
Les btrfsdéveloppeurs recommandent donc d'augmenter successivement la limite d'utilisation de "quand les blocs de données doivent être réorganisés pour récupérer de l'espace"
Par conséquent, si le résultat de
$> sudo btrfs balance -dusage=0
Done, had to relocate 0 out of 170 chunks
ne montre aucune délocalisation, il faut faire
$> sudo btrfs balance -dusage=5
Done, had to relocate 0 out of 170 chunks <--(again fail)
$> sudo btrfs balance -dusage=10
Done, had to relocate 0 out of 170 chunks <--(again fail)
$> sudo btrfs balance -dusage=15
Done, had to relocate 2 out of 170 chunks <--(success)
L'autre réponse a fait allusion à l'influence de la btrfstaille du nœud, qui influence quelque peu la vitesse à laquelle les métadonnées augmenteront. La taille du nœud n'est (comme mentionné dans l'autre réponse) définie qu'une seule fois au mkfs.btrfsmoment de la création du système de fichiers. En théorie, on pourrait réduire la taille des métadonnées s'il était possible de passer à une valeur inférieure pour la taille du nœud, si c'était possible (ce n'est pas le cas!). La taille du nœud, cependant, ne pourra en aucun cas aider à étendre ou augmenter l'espace de métadonnées alloué. Au lieu de cela, cela aurait pu seulement aider à conserver de l'espace en premier lieu. Une taille de nœud plus petite n'est cependant pas garantie pour réduire la taille des métadonnées. En effet, certains cas peuvent montrer que des nœuds plus grands réduisent la longueur de parcours d'arborescence de btrfs, car les notes peuvent contenir plus de "liens".