TL; DR I metadati (se il btrfs non soffre di condizioni generali di spazio ridotto) aumenteranno automaticamente . Nei casi in cui non esiste spazio libero non allocato, l'incremento automatico è limitato. Se, tuttavia, la parte di dati di btrfsè stata allocata più spazio del necessario, è possibile ridistribuire questo. Questo si chiama balance-ing in btrfs.
Supponendo che ci sia abbastanza memoria non btrfsallocata sui dispositivi del backing block del / i dispositivo / i , allora la parte Metadata del filesystem alloca - proprio come assunto dall'OP - la memoria automaticamente per aumentare / espandere i metadati.
Pertanto, la risposta è: Sì (a condizione che non ci siano condizioni di memoria insufficiente / spazio libero in btrfs) , i metadati verranno automaticamente aumentati, in quanto tali:
(1) Diamo un'occhiata ad alcune impostazioni iniziali di allocazione del btrfs (su un 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) Come si può vedere, lo spazio allocato nel filesystem per l'archiviazione dei metadati è 1,55GiB, di cui 1,33GiB, quindi quasi tutto viene utilizzato (questa potrebbe essere una situazione che si verifica nel caso del PO)
(3) Provochiamo ora un aumento dei metadati da aggiungere. Per fare ciò, copiamo la cartella / home usando l' --reflink=alwaysopzione del cpcomando.
$> cp -r --reflink=awlways /home /home.copy
(4) Poiché (dato che presumiamo che ci fossero molti file in / home), sono stati aggiunti molti nuovi dati al filesystem, che poiché abbiamo usato --reflinknon utilizza spazio aggiuntivo per i dati effettivi, utilizza Copy-on-Write, meccanismo. In breve, principalmente Metadata sono stati aggiunti al filesystem. Possiamo quindi avere un altro aspetto
$> 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
Come si può vedere, lo spazio allocato per i metadati utilizzati in questo btrfsè aumentato automaticamente .
Dal momento che questo è così automaticamente, normalmente non viene rilevato dall'utente. Tuttavia, ci sono alcuni casi, principalmente quelli in cui l'intero filesystem è già praticamente riempito. In questi casi, btrfspotrebbe iniziare a "balbettare" e non riuscire ad aumentare automaticamente lo spazio allocato per i metadati. Il motivo sarebbe, ad esempio, che tutto lo spazio è già stato allocato alle parti (Dati, Sistema, Metadati, GlobalReserve). Confusamente, potrebbe essere ancora il caso che ci sia spazio apparente. Un esempio potrebbe essere questo output:
$> 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
Come si può vedere, il sistema è tutto 40GiB, ma l'allocazione è in qualche modo disattivata balance, poiché mentre c'è ancora spazio per i dati dei nuovi file, i metadati (come nel caso OP) sono bassi. L'allocazione automatica della memoria per i dispositivi che supportano il btrfsfilesystem non è più possibile (è sufficiente sommare i totali dell'allocazione, 38.12G + 1.55G + .. ~ = 40GiB).
Poiché esiste tuttavia uno spazio libero in eccesso allocato alla dataparte del file system, ora può essere utile, necessario per bilanciare btrfs. Equilibrio significherebbe ridistribuire lo spazio già assegnato.
Nel caso del PO, si può presumere che, per qualche motivo, si sia verificato uno squilibrio tra le diverse parti btrfsdell'assegnazione.
Sfortunatamente, il semplice comando sudo btrfs balance -dusage=0, che in linea di principio dovrebbe cercare blocchi vuoti (allocati per i dati) e metterli a un utente migliore (che sarebbe lo spazio quasi esaurito per i metadati), potrebbe non riuscire, perché non è possibile trovare blocchi di dati completamente vuoti.
Gli btrfssviluppatori raccomandano quindi di aumentare successivamente il limite di utilizzo di "quando i blocchi di dati devono essere riorganizzati per recuperare spazio"
Quindi, se il risultato di
$> sudo btrfs balance -dusage=0
Done, had to relocate 0 out of 170 chunks
non mostra alcun trasferimento, si dovrebbe fare un po '
$> 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'altra risposta ha suggerito l'influenza della dimensione dei btrfsnodi, che influenza in qualche modo la velocità con cui i metadati aumenteranno. La dimensione del nodo è (come menzionato nell'altra risposta) impostata una sola volta al mkfs.btrfsmomento della creazione del filesystem. In teoria, si potrebbe ridurre la dimensione dei metadati se fosse possibile passare a un valore più basso per la dimensione dei nodi, se ciò fosse possibile (non lo è!). La dimensione dei nodi, tuttavia, non sarà in grado di aiutare ad espandere o aumentare lo spazio dei metadati allocato in alcun modo. Invece, avrebbe potuto aiutare a conservare lo spazio in primo luogo. Una dimensione di nodo inferiore, tuttavia, non è garantita per ridurre la dimensione dei metadati. In effetti, alcuni casi potrebbero mostrare che nodi più grandi riducono la lunghezza di btrfs traversale, in quanto le note possono contenere più "collegamenti".