Um contentor parado pode deixar um instantâneo Btrfs ocupado quando outro processo, espaço de nomes de montagem, montagem bind, tarefa de envio ou subvolume aninhado continua a referenciá-lo.
Parar um contentor de aplicação termina o processo principal, mas não prova que todas as montagens relacionadas, processos auxiliares, intermediários do runtime, sessões de shell, tarefas de cópia de segurança ou espaços de nomes tenham libertado o caminho do instantâneo. O Btrfs também pode rejeitar a eliminação quando o destino está montado, envolvido numa operação de envio, configurado como subvolume predefinido ou contém subvolumes aninhados. Diagnostique a referência exata antes de forçar a desmontagem ou eliminar dados do contentor.
Confirme o objeto Btrfs exato e o erro
Registe o caminho completo do instantâneo, o ID do subvolume, o ID do principal, o estado só de leitura, o UUID, o UUID recebido e o erro exato de eliminação. Confirme que o caminho é um subvolume Btrfs e não um diretório normal dentro de um subvolume.
A referência aos subvolumes Btrfs explica que os instantâneos são subvolumes e documenta as condições que impedem a eliminação, incluindo o estado de subvolume predefinido e uma operação de envio ativa.
Se o erro não for EBUSY, siga a falha efetiva. Problemas de permissões, montagem só de leitura, subvolume predefinido e subvolumes aninhados exigem verificações diferentes das de uma referência de montagem ativa.
Separe a paragem do contentor da remoção do contentor
Liste os contentores nos estados em execução, parados, terminados e em remoção. Registe os IDs dos contentores que utilizaram o instantâneo através de montagens bind, volumes nomeados ou de um controlador de armazenamento Btrfs.
A referência da CLI do Docker mostra que o docker stop envia um sinal ao processo principal; isso não significa que a definição do contentor, os metadados do runtime ou todas as relações de armazenamento no anfitrião tenham sido removidos.
Não elimine o instantâneo apenas porque a interface da aplicação indica que a pilha está parada. Verifique se ainda existe uma política de reinício, um auxiliar de verificação do estado, uma shell exec, um contentor secundário ou um processo do runtime do contentor.
Inspecione as montagens em todos os espaços de nomes relevantes
Compare a tabela de montagens do anfitrião com os espaços de nomes de montagem do runtime do contentor, dos auxiliares de contentores parados, dos agentes de cópia de segurança e de qualquer shell persistente que tenha entrado no contentor.
O manual do Linux explica que os espaços de nomes de montagem isolam as listas de montagens, pelo que um caminho pode parecer desmontado no anfitrião e continuar montado noutro espaço de nomes de processos.
Utilize informações de montagem específicas do processo em vez de verificar apenas a shell atual. Uma desmontagem diferida no anfitrião pode ocultar o sintoma sem libertar o espaço de nomes que ainda mantém a referência.
Procure montagens de contentores que tenham sobrevivido noutro espaço de nomes
Identifique o ID do processo do runtime do contentor, do intermediário, do agente de monitorização ou do auxiliar que possa manter o espaço de nomes. Inspecione a respetiva árvore de montagens e o caminho de origem correspondente ao instantâneo Btrfs.
A Red Hat documenta um caso verificado em que uma montagem noutro espaço de nomes provoca erros de limpeza de dispositivo ou recurso ocupado, correspondendo à situação em que o anfitrião parece estar limpo, mas o instantâneo continua referenciado.
Termine apenas o auxiliar obsoleto comprovado ou reinicie o runtime relevante durante uma janela de manutenção. Terminar proprietários de espaços de nomes não relacionados pode interromper outros contentores e montagens.
Utilize verificações com fuser e identificadores abertos tendo em conta os limites dos espaços de nomes
Verifique ficheiros abertos, diretórios de trabalho atuais, ficheiros mapeados e utilizadores de montagens no caminho do instantâneo. Execute as ferramentas com privilégios suficientes e compare a respetiva lista de processos com os processos do runtime.
O manual do fuser do Debian avisa que a ferramenta pode não detetar dispositivos de bloco montados por processos noutro espaço de nomes de montagem, pelo que um resultado vazio não prova que o instantâneo não esteja a ser utilizado.
Verifique também sessões de shell cujo diretório atual esteja dentro do instantâneo, serviços de indexação de ficheiros, analisadores antivírus, leitores de cópias de segurança e processos que acompanhem os registos da aplicação. Feche um utilizador confirmado de cada vez e repita a verificação de estado só de leitura.
Exclua subvolumes montados, predefinidos, aninhados e em envio
Liste todas as montagens que correspondam ao ID de subvolume do instantâneo, verifique o subvolume predefinido do sistema de ficheiros, enumere os subvolumes subordinados aninhados e inspecione as tarefas de envio Btrfs ativas.
A ArchWiki aconselha que um subvolume montado não deve ser eliminado, tornando a identidade da montagem e a estrutura aninhada verificações necessárias antes da remoção.
Parar contentores de aplicações não interrompe um envio Btrfs independente, a replicação de instantâneos ou um processo de cópia de segurança. Aguarde que o envio termine ou pare-o corretamente e, em seguida, verifique novamente o estado do instantâneo.
Liberte a referência comprovada e elimine em segurança
Desmonte o instantâneo a partir do espaço de nomes que o possui, remova ou reinicie o objeto obsoleto do runtime do contentor quando apropriado, saia dos diretórios de trabalho, pare a tarefa de envio confirmada e elimine os subvolumes aninhados pela ordem das dependências.
O artigo da ZimaSpace sobre criar instantâneos dos dados de aplicações NAS fornece o contexto adicional para identificar quais os caminhos persistentes e estados da aplicação abrangidos efetivamente por um instantâneo de contentor.
O problema fica resolvido quando nenhum espaço de nomes ou processo referencia o subvolume, o instantâneo não predefinido correto é eliminado através do comando Btrfs suportado, a limpeza em segundo plano termina e a pilha da aplicação reinicia com os caminhos de dados ativos pretendidos intactos.
Suporte e Dicas
Mais para Ler

O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...

Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...

Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...

