¿Por qué se detiene el equilibrado de Btrfs después de mover los datos a una unidad más grande?
Un balanceo de Btrfs puede parecer detenido después de añadir una unidad más grande porque la reubicación aún necesita espacio de trabajo libre para los fragmentos y quizá esté moviendo todo el sistema de archivos.
Reemplazar datos o copiarlos a un dispositivo más grande no compacta, distribuye uniformemente ni hace que todos los grupos de bloques de Btrfs sean aptos para la reubicación automáticamente. Un balanceo funciona a nivel de grupo de bloques, crea espacio de trabajo temporal, actualiza los metadatos y puede estar limitado por el dispositivo más lento, las instantáneas, las sumas de comprobación u otra operación exclusiva. La primera tarea es distinguir una reubicación realmente bloqueada de un balanceo completo lento que aún sigue avanzando.
Confirma si el balanceo está en ejecución, pausado o esperando
Comprueba el estado del balanceo, el número de fragmentos procesados, el registro del kernel, el rendimiento de los discos y la latencia de cada dispositivo. Registra si el comando se ejecuta en primer plano, en segundo plano, pausado, cancelado o reanudado automáticamente después de reiniciar.
Un balanceo puede pasar mucho tiempo reubicando un grupo de bloques muy utilizado antes de que cambie el contador visible. La guía de Btrfs de ArchWiki muestra el uso del estado del balanceo y del uso del sistema de archivos para distinguir el trabajo que continúa de un comando que ya se ha detenido.
Si no hay E/S, no cambia el estado y el registro del kernel informa de un error, considéralo detenido en lugar de lento. Conserva el primer mensaje de error antes de reiniciar el balanceo con filtros diferentes.
Verifica que el dispositivo más grande y el sistema de archivos se hayan redimensionado
Compara el tamaño físico del dispositivo, el tamaño de la partición, el tamaño del dispositivo Btrfs y la asignación del sistema de archivos. Un disco de reemplazo más grande aún puede exponer el límite anterior de la partición o el tamaño anterior del dispositivo Btrfs.
Confirma cada capa en orden: capacidad del hardware, tabla de particiones, dispositivo de bloques, inventario de dispositivos Btrfs y asignación del sistema de archivos. SUSE documenta que el dispositivo debe ampliarse antes que el sistema de archivos, por lo que un balanceo no puede utilizar una capacidad que Btrfs aún no detecta.
El artículo de ZimaSpace sobre la capacidad que no aumenta después de reemplazar una unidad ofrece la comprobación por capas relacionada antes de atribuir el problema a la reubicación.
Distingue entre bytes libres y espacio de trabajo libre para fragmentos
Compara el tamaño total del dispositivo con la cantidad ya asignada a los grupos de bloques de Btrfs. Un sistema de archivos puede mostrar bytes libres a los usuarios y, aun así, carecer de una región completamente sin asignar lo bastante grande como para crear el grupo de bloques temporal necesario para la reubicación.
La documentación del balanceo de Btrfs explica que la reubicación necesita espacio de trabajo de grupos de bloques completamente sin usar; esto difiere del espacio libre normal a nivel de archivos y puede producir ENOSPC durante el balanceo.
Si el espacio de trabajo es limitado, recupera primero los grupos de bloques completamente sin usar con un filtro de uso específico, en lugar de iniciar otro balanceo completo. No elimines instantáneas indiscriminadamente hasta medir su contribución a la asignación de fragmentos.
Comprueba si se inició un balanceo completo sin filtros
Revisa el comando original. Un balanceo sin filtros de datos o metadatos intenta reubicar todo el sistema de archivos, incluso cuando el objetivo real es solo compactar fragmentos poco utilizados o trasladar asignaciones fuera de un dispositivo.
Un balanceo completo puede tardar muchas horas o días porque se reescribe cada grupo de bloques seleccionado. El manual de btrfs-balance de Linux advierte que ejecutarlo sin filtros mueve datos y metadatos por todo el sistema de archivos y actualiza todos los punteros de bloques.
Usa la salida del estado y el historial anterior del shell para identificar los filtros activos. No canceles y reinicies repetidamente, ya que los balanceos interrumpidos pueden dejar grupos de bloques parcialmente llenos que sigan consumiendo espacio de trabajo.
Comprueba si hay dispositivos lentos, errores y operaciones exclusivas simultáneas
Inspecciona los datos SMART, los errores de transporte, los reinicios de enlace, los tiempos de espera de USB o SATA y la latencia de cada dispositivo. La velocidad del balanceo está limitada por las lecturas de las ubicaciones antiguas, las escrituras en las nuevas, la verificación de las sumas de comprobación y las actualizaciones de metadatos.
Comprueba también si hay un scrub, adición o eliminación de dispositivos, redimensionamiento del sistema de archivos, eliminación de instantáneas, operaciones de envío o recepción y otras tareas de almacenamiento. La guía de administración de Btrfs de Red Hat describe los cambios de dispositivos y el balanceo como operaciones de reubicación, por lo que un mantenimiento simultáneo puede generar una gran contención aunque ningún disco haya fallado.
Si un dispositivo muestra reinicios repetidos o una latencia extrema, pausa el balanceo y diagnostica esa ruta antes de forzar más reubicaciones. Continuar con un dispositivo inestable puede convertir un problema de rendimiento en un problema de recuperación.
Usa filtros y límites específicos para reiniciar de forma controlada
Después de conservar el estado actual, empieza con el filtro de menor riesgo que apunte a grupos de bloques vacíos o poco utilizados. Limita el número de fragmentos por ejecución para poder observar cada resultado antes de ampliar el alcance.
Aumenta gradualmente el umbral de uso y trata los datos y los metadatos por separado. La reubicación de metadatos puede generar muchas actualizaciones adicionales y no es necesario compactarla agresivamente solo porque la utilización media parezca baja.
Pausa, reanuda o cancela mediante los controles de balanceo compatibles, en lugar de finalizar el proceso a la fuerza. Confirma que se complete el grupo de bloques actual y que el estado guardado del balanceo coincida con la siguiente acción.
Verifica la distribución y la capacidad después del balanceo
Compara la asignación por dispositivo, los perfiles de datos y metadatos, el espacio de trabajo sin asignar, el uso del sistema de archivos y el número de fragmentos reubicados antes y después del balanceo controlado.
Un resultado satisfactorio no implica necesariamente que el uso en bytes sea perfectamente igual en todas las unidades. La descripción general del kernel de Linux enumera la compatibilidad integrada con varios dispositivos y el redimensionamiento en línea, por lo que la prueba final debe centrarse en perfiles válidos, asignación utilizable, dispositivos en buen estado y espacio de trabajo suficiente para futuras escrituras.
El problema se resuelve cuando el balanceo termina o alcanza el alcance filtrado previsto, el dispositivo más grande recibe nuevas asignaciones, se restaura el espacio de trabajo libre para fragmentos y las escrituras normales, las instantáneas, el scrub y los reinicios funcionan sin que el balanceo se reinicie inesperadamente.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
