¿Por qué una instantánea de Btrfs sigue ocupada después de que se detienen todos los contenedores de aplicaciones?
Un contenedor detenido puede mantener ocupado un snapshot de Btrfs cuando otro proceso, espacio de nombres de montaje, montaje bind, tarea de envío o subvolumen anidado aún lo referencia.
Detener un contenedor de aplicaciones finaliza su proceso principal, pero no demuestra que todos los montajes relacionados, procesos auxiliares, interfaces del entorno de ejecución, sesiones de shell, tareas de copia de seguridad o espacios de nombres hayan liberado la ruta del snapshot. Btrfs también puede rechazar la eliminación cuando el destino está montado, participa en un envío, está configurado como subvolumen predeterminado o contiene subvolúmenes anidados. Diagnostica la referencia exacta antes de forzar un desmontaje o eliminar los datos del contenedor.
Confirma el objeto y el error exactos de Btrfs
Registra la ruta completa del snapshot, el ID del subvolumen, el ID del principal, el estado de solo lectura, el UUID, el UUID recibido y el error exacto de eliminación. Confirma que la ruta es un subvolumen de Btrfs y no un directorio normal dentro de uno.
La referencia de subvolúmenes de Btrfs explica que los snapshots son subvolúmenes y documenta las condiciones que impiden su eliminación, incluido el estado de subvolumen predeterminado y una operación de envío activa.
Si el error no es EBUSY, sigue la causa real del fallo. Los problemas de permisos, montaje de solo lectura, subvolumen predeterminado y subvolúmenes anidados requieren comprobaciones distintas de las de una referencia de montaje activa.
Distingue entre detener y eliminar un contenedor
Enumera los contenedores en los estados en ejecución, detenidos, finalizados y en proceso de eliminación. Registra los ID de los contenedores que utilizaron el snapshot mediante montajes bind, volúmenes con nombre o un controlador de almacenamiento Btrfs.
La referencia de la CLI de Docker muestra que docker stop envía una señal al proceso principal; esto no significa que se hayan eliminado la definición del contenedor, los metadatos del entorno de ejecución ni todas las relaciones de almacenamiento del host.
No elimines el snapshot simplemente porque la interfaz de la aplicación indique que la pila está detenida. Comprueba si todavía existe una política de reinicio, un auxiliar de comprobación de estado, una shell de ejecución, un contenedor auxiliar o un proceso del entorno de ejecución.
Inspecciona los montajes en todos los espacios de nombres relevantes
Compara la tabla de montajes del host con los espacios de nombres de montaje del entorno de ejecución del contenedor, los auxiliares de contenedores detenidos, los agentes de copia de seguridad y cualquier shell persistente que haya entrado en el contenedor.
El manual de Linux explica que los espacios de nombres de montaje aíslan las listas de montajes, por lo que una ruta puede aparecer desmontada en el host mientras permanece montada dentro del espacio de nombres de otro proceso.
Usa información de montajes específica de cada proceso en lugar de comprobar únicamente la shell actual. Un desmontaje diferido desde el host puede ocultar el síntoma sin liberar el espacio de nombres que aún mantiene la referencia.
Busca montajes de contenedores que hayan sobrevivido en otro espacio de nombres
Identifica el ID de proceso del entorno de ejecución del contenedor, la interfaz, el agente de supervisión o el auxiliar que podría conservar el espacio de nombres. Inspecciona su árbol de montajes y la ruta de origen correspondiente al snapshot de Btrfs.
Red Hat documenta un caso verificado en el que un montaje en otro espacio de nombres provoca errores de limpieza por dispositivo o recurso ocupado, lo que coincide con la situación en la que el host parece estar libre, pero el snapshot aún está referenciado.
Finaliza únicamente el auxiliar obsoleto confirmado o reinicia el entorno de ejecución correspondiente durante una ventana de mantenimiento. Finalizar propietarios de espacios de nombres no relacionados puede interrumpir otros contenedores y montajes.
Usa fuser y comprobaciones de archivos abiertos teniendo en cuenta los límites de los espacios de nombres
Comprueba los archivos abiertos, los directorios de trabajo actuales, los archivos mapeados y los usuarios del montaje bajo la ruta del snapshot. Ejecuta las herramientas con privilegios suficientes y compara su lista de procesos con los procesos del entorno de ejecución.
El manual de fuser de Debian advierte que puede no detectar dispositivos de bloques montados por procesos en un espacio de nombres de montaje diferente, por lo que un resultado vacío no demuestra que el snapshot no se esté utilizando.
Comprueba también las sesiones de shell cuyo directorio actual esté dentro del snapshot, los servicios de indexación de archivos, los escáneres antivirus, los lectores de copias de seguridad y los procesos que siguen los registros de la aplicación. Cierra un usuario confirmado cada vez y vuelve a intentar la comprobación de estado de solo lectura.
Descarta subvolúmenes montados, predeterminados, anidados y en proceso de envío
Enumera todos los montajes que se resuelvan en el ID del subvolumen del snapshot, comprueba el subvolumen predeterminado del sistema de archivos, enumera los subvolúmenes secundarios anidados e inspecciona las tareas activas de envío de Btrfs.
ArchWiki indica que no debe eliminarse un subvolumen montado, por lo que es necesario comprobar la identidad del montaje y la estructura anidada antes de eliminarlo.
Detener los contenedores de aplicaciones no detiene un envío independiente de Btrfs, la replicación de snapshots ni un proceso de copia de seguridad. Espera a que finalice el envío o detenlo correctamente y, después, vuelve a comprobar el estado del snapshot.
Libera la referencia confirmada y elimina de forma segura
Desmonta el snapshot desde el espacio de nombres que lo posee, elimina o reinicia el objeto obsoleto del entorno de ejecución del contenedor cuando corresponda, sal de los directorios de trabajo, detén la tarea de envío confirmada y elimina los subvolúmenes anidados siguiendo el orden de dependencias.
El artículo de ZimaSpace sobre la creación de snapshots de los datos de aplicaciones NAS ofrece el contexto relacionado para identificar qué rutas persistentes y estados de aplicación cubre realmente un snapshot de contenedor.
El problema se resuelve cuando ningún espacio de nombres ni proceso referencia el subvolumen, el snapshot no predeterminado correcto se elimina mediante el comando de Btrfs compatible, finaliza la limpieza en segundo plano y la pila de aplicaciones se reinicia con sus rutas de datos activas previstas intactas.
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...
