TL; DR Os metadados (se o btrfs não estiver sofrendo uma condição geral de baixo espaço) aumentarão automaticamente . Nos casos em que não existe espaço livre não alocado, o aumento automático é combinado. Se, no entanto, a parte de dados de btrfs foi alocada mais espaço do que o necessário, então é possível redistribuir isso. Isso é chamado de balance -ing no btrfs.
Supondo que haja memória suficiente não alocada no (s) dispositivo (s) de bloco de apoio do btrfs , a parte de metadados do sistema de arquivos aloca automaticamente a memória para aumentar / expandir os metadados.
Portanto, a resposta é: Sim (desde que não haja pouca memória / condição de espaço livre no btrfs ) , os metadados serão automaticamente aumentados, assim:
(1) Observamos algumas configurações de alocação inicial do btrfs (em um dispositivo 40GB )
$> 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 como ocorrendo no caso do OP)
(3) Provocamos agora um aumento de metadados a serem adicionados. Para fazer isso, copiamos a pasta / home usando a opção --reflink=always do comando cp .
$> cp -r --reflink=awlways /home /home.copy
(4) Desde (como assumimos que havia muitos arquivos em / home), que muitos novos dados para o sistema de arquivos foram adicionados, que porque usamos --reflink usa pouco ou nenhum espaço adicional para o dados reais, ele usa o mecanismo Copy-on-Write. Em suma, a maioria dos metadados foi adicionada ao sistema de arquivos. Podemos ter, portanto, 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 os metadados usados neste btrfs tem automaticamente aumentado expandido.
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á bem preenchido. Nesses casos, btrfs pode começar a "gaguejar" e não 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 (Data, System, Metadata, GlobalReserve). Confusamente, ainda pode ser que haja espaço aparente. Um exemplo seria essa 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, o sistema todo o 40GiB , mas a alocação está um pouco fora balance , já que enquanto ainda há espaço para os dados dos novos arquivos, os Metadados (como no caso do OP) são baixo. A alocação automática de memória para os dispositivos que suportam o sistema de arquivos btrfs não é mais possível (basta somar os totais da alocação, 38.12G + 1.55G + .. ~ = 40GiB).
Já que há espaço livre em excesso alocado para a parte data do sistema de arquivos, agora pode ser útil, necessário para equilibrar o btrfs. Equilíbrio significaria redistribuir o espaço já alocado.
No caso do OP, pode-se supor que, por algum motivo, ocorreu um desequilíbrio entre as diferentes partes da alocação btrfs .
Infelizmente, o comando simples sudo btrfs balance -dusage=0 , que em princípio deve procurar blocos vazios (alocados para dados) e colocá-los em um usuário melhor (que seria o espaço quase esgotado para Metadados), pode falhar, porque não há dados completamente vazios blocos podem ser encontrados.
Os desenvolvedores btrfs recomendam 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
não está mostrando nenhuma mudança, deve-se fazer algumas
$> 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 btrfs nodesize, que influencia um pouco a rapidez com que os metadados aumentam. O tamanho do nós é (como mencionado na outra resposta) definido apenas uma vez no tempo de criação do sistema de arquivos mkfs.btrfs . Em teoria, poderia-se reduzir o tamanho dos Metadados se fosse possível mudar para um valor menor para o tamanho do nós, 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 alguma forma. Em vez disso, pode ter ajudado apenas a economizar espaço em primeiro lugar. No entanto, um tamanho de nós menor não é garantido para reduzir o tamanho dos metadados. De fato, alguns casos podem mostrar que nós maiores reduzem o comprimento do percurso da árvore do btrfs, já que as notas podem conter mais "links".