TL; DR Os metadados (se o btrfs não estiver sofrendo uma condição geral de pouco espaço) aumentarão automaticamente . Nos casos em que não existe espaço livre não alocado, o aumento automático é impedido. Se, no entanto, a parte dos dados btrfstiver sido alocada com mais espaço do que precisa, será possível redistribuí-lo. Isso é chamado de balance-ing no btrfs.
Supondo que haja memória não alocada suficiente no (s) dispositivo (s) de bloco de apoio do btrfs, a parte Metadados do sistema de arquivos aloca - exatamente como assumido pelo OP - automaticamente a memória para aumentar / expandir os metadados.
Portanto, a resposta é: Sim (desde que não haja pouca condição de memória / espaço livre no btrfs) , os metadados serão automaticamente aumentados, como tal:
(1) Vimos algumas configurações de alocação inicial dos btrfs (em um 40GBdispositivo)
$> 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) Como pode ser visto, o espaço alocado no sistema de arquivos para armazenar metadados é 1,55GiB, dos quais 1,33GiB, portanto quase todos são usados (isso pode ser uma situação que ocorre no caso do OP)
(3) Agora provocamos um aumento de metadados a serem adicionados. Para fazer isso, copiamos a pasta / home usando a --reflink=alwaysopção do cpcomando
$> cp -r --reflink=awlways /home /home.copy
(4) Como (como assumimos que havia muitos arquivos em / home), que muitos dados novos foram adicionados ao sistema de arquivos, que, porque --reflinkusamos pouco espaço para os dados reais, ele usa o método Mecanismo Copy-on-Write. Em resumo, a maioria dos metadados foi adicionada ao sistema de arquivos. Podemos, portanto, ter outro olhar
$> 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
Como pode ser visto, o espaço alocado para Metadados usado neste btrfstem automaticamente aumentada expandida.
Como isso é automático, normalmente não é detectado pelo usuário. No entanto, existem alguns casos, principalmente aqueles em que todo o sistema de arquivos já está praticamente cheio. Nesses casos, btrfspode começar a "gaguejar" e falhar ao aumentar automaticamente o espaço alocado para os metadados. O motivo seria, por exemplo, que todo o espaço já tenha sido alocado para as partes (Dados, Sistema, Metadados, GlobalReserve). De maneira confusa, pode ser que exista espaço aparente. Um exemplo seria esta saída:
$> 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
Como pode ser visto, todo o sistema 40GiB, mas a alocação está um pouco desativada balance, pois enquanto ainda há espaço para os dados dos novos arquivos, os Metadados (como no caso do OP) são baixos. A alocação automática de memória para os dispositivos que btrfsfazem o backup do sistema de arquivos não é mais possível (basta somar os totais da alocação, 38,12G + 1,55G + .. ~ = 40GiB).
Como existe, no entanto, espaço livre em excesso que foi alocado para a dataparte do sistema de arquivos, agora pode ser útil, necessário para equilibrar os btrfs. O saldo significaria redistribuir o espaço já alocado.
No caso do PO, pode-se supor que, por algum motivo, btrfsocorreu um desequilíbrio entre as diferentes partes da alocação.
Infelizmente, o comando simples sudo btrfs balance -dusage=0, que em princípio deve procurar blocos vazios (alocados para dados) e colocá-los para um melhor usuário (que seria o espaço quase esgotado para os metadados), pode falhar, porque nenhum bloco de dados completamente vazio pode ser encontrado.
Os btrfsdesenvolvedores recomendam, portanto, aumentar sucessivamente o limite de uso de "quando os blocos de dados devem ser reorganizados para recuperar espaço"
Portanto, se o resultado de
$> sudo btrfs balance -dusage=0
Done, had to relocate 0 out of 170 chunks
está mostrando nenhuma realocação, deve-se fazer alguma
$> 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)
A outra resposta sugeriu a influência do btrfstamanho do nó, que influencia um pouco a rapidez com que os metadados aumentarão. O tamanho do nó (como mencionado na outra resposta) é definido apenas uma vez no mkfs.btrfsmomento da criação do sistema de arquivos. Em teoria, seria possível reduzir o tamanho dos metadados se fosse possível mudar para um valor menor para o tamanho do nó, se isso fosse possível (não é!). O tamanho do nó, no entanto, não poderá ajudar a expandir ou aumentar o espaço de metadados alocado de forma alguma. Em vez disso, pode ter ajudado a economizar espaço em primeiro lugar. No entanto, um tamanho de nó menor não é garantido para reduzir o tamanho dos metadados. De fato, alguns casos podem mostrar que tamanhos de nós maiores reduzem o comprimento de travessia de árvore do btrfs, pois as notas podem conter mais "links".