TL; DR Los metadatos (si el btrfs no sufre condiciones generales de poco espacio) aumentará automáticamente . En los casos en que no exista espacio libre no asignado, el aumento automático se divide. Sin embargo, si a la parte de datos btrfsse le ha asignado más espacio del que necesita, entonces es posible redistribuir esto. Esto se llama balance-ing en btrfs.
Suponiendo que hay suficiente memoria no asignada en los dispositivos de bloque de respaldo del btrfs, entonces la parte de Metadatos del sistema de archivos asigna, tal como lo supone el OP, memoria automáticamente para aumentar / expandir los metadatos.
Por lo tanto, la respuesta es: Sí (siempre que no haya poca memoria / condición de espacio libre en el btrfs) , entonces los metadatos aumentarán automáticamente, como tal:
(1) Echamos un vistazo a la configuración de asignación inicial de btrfs (en 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) Como se puede ver, el espacio asignado en el sistema de archivos para almacenar Metadatos es 1.55GiB, de los cuales 1.33GiB, por lo tanto, se usa casi todo (esto podría ser una situación que ocurre en el caso del OP)
(3) Ahora provocamos un aumento de metadatos que se agregarán. Para hacerlo, copiamos la carpeta / home usando la --reflink=alwaysopción del cpcomando.
$> cp -r --reflink=awlways /home /home.copy
(4) Dado que (como suponemos que había muchos archivos en / home), que se han agregado muchos datos nuevos al sistema de archivos, que debido a que --reflinkusamos poco o ningún espacio adicional para los datos reales, utiliza el Copia en escritura, mecanismo. En resumen, la mayoría de los metadatos se agregaron al sistema de archivos. Por lo tanto, podemos tener otra mirada
$> 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 se puede ver, el espacio asignado para los metadatos utilizados en esto se btrfsha ampliado automáticamente .
Como esto es tan automático, normalmente el usuario no lo detecta. Sin embargo, hay algunos casos, principalmente aquellos en los que todo el sistema de archivos ya está bastante lleno. En esos casos, btrfspuede comenzar a "tartamudear" y no aumentar automáticamente el espacio asignado para los metadatos. La razón sería, por ejemplo, que todo el espacio ya ha sido asignado a las partes (Datos, Sistema, Metadatos, GlobalReserve). Confusamente, podría ser el caso de que haya espacio aparente. Un ejemplo sería esta salida:
$> 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 se puede ver, todo el sistema 40GiB, sin embargo, la asignación está algo apagada balance, ya que si bien todavía hay espacio para los datos de los nuevos archivos, los metadatos (como en el caso de OP) son bajos. La asignación automática de memoria para los dispositivos que respaldan el btrfssistema de archivos ya no es posible (simplemente sume los totales de la asignación, 38.12G + 1.55G + .. ~ = 40GiB).
Sin embargo, dado que hay un espacio libre en exceso asignado a la dataparte del sistema de archivos, ahora puede ser útil, necesario para equilibrar los btrfs. Equilibrio significaría redistribuir el espacio ya asignado.
En el caso del OP, se puede suponer que, por alguna razón, se btrfsha producido un desequilibrio entre las diferentes partes de la asignación.
Desafortunadamente, el comando simple sudo btrfs balance -dusage=0, que en principio debería buscar bloques vacíos (asignados para datos) y ponerlos a un mejor usuario (que sería el espacio casi agotado para los metadatos), puede fallar, porque no se pueden encontrar bloques de datos completamente vacíos.
Los btrfsdesarrolladores recomiendan, por lo tanto, aumentar sucesivamente el límite de uso de "cuando los bloques de datos deben reorganizarse para reclamar espacio"
Por lo tanto, si el resultado de
$> sudo btrfs balance -dusage=0
Done, had to relocate 0 out of 170 chunks
no muestra reubicación, uno debería hacer algo
$> 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)
La otra respuesta ha insinuado la influencia del btrfstamaño de los nodos, que influye de alguna manera en la rapidez con que aumentarán los metadatos. El tamaño de los nodos (como se menciona en la otra respuesta) solo se establece una vez en el mkfs.btrfsmomento de creación del sistema de archivos. En teoría, uno podría reducir el tamaño de los metadatos si fuera posible cambiar a un valor más bajo para el tamaño de los nodos, si eso fuera posible (¡no lo es!). Sin embargo, el tamaño de los nodos no podrá ayudar a expandir o aumentar el espacio de metadatos asignado de ninguna manera. En cambio, podría haber ayudado a conservar espacio en primer lugar. Sin embargo, no se garantiza un tamaño de nodo más pequeño para reducir el tamaño de los metadatos. De hecho, algunos casos pueden mostrar que los tamaños de nodos más grandes reducen la longitud transversal del árbol de btrfs, ya que las notas pueden contener más "enlaces".