+1, estou muito interessado em ouvir alguma discussão sobre este assunto. Minha estratégia até agora tem sido

• tenha cuidado com o que você constrói / puxa
• esteja preparado para explodir seu / var / lib / docker: neutral_face:

@AaronFriel , em qual versão do Docker você está? 0.7.1?

/ cc @regilero (link também para # 2276)

A partir de um / var / lib / docker novo:

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
292M -rw-------. 1 root root 100G Dec 12 17:29 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root   89 Dec 12 17:29 /var/lib/docker/devicemapper/devicemapper/json
732K -rw-------. 1 root root 2.0G Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

Então, depois que o docker pull busybox cresceu um pouco:

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
297M -rw-------. 1 root root 100G Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root  181 Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/json
756K -rw-------. 1 root root 2.0G Dec 12 17:31 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 1
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 296.6 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

docker rmi busybox _não_ torna o arquivo maior, mas deixa o espaço livre no pool do mapeador de dispositivos:

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
298M -rw-------. 1 root root 100G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root   89 Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/json
772K -rw-------. 1 root root 2.0G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

O arquivo de loopback não aumenta se baixarmos a imagem novamente:

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
298M -rw-------. 1 root root 100G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root  181 Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/json
772K -rw-------. 1 root root 2.0G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 1
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 296.6 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

Portanto, parece que falhamos em esparsificar o arquivo de loopback quando o dispositivo thinp descarta um bloco.

No entanto, se eu criar um arquivo dentro da imagem fs do contêiner, ele _does_ recuperará o espaço no arquivo de loopback.
Ou seja, eu fiz isso na imagem do busybox:

 cd lib
 cat libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 lib
c.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so
.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 libc.so.6 > a_file.bin
/lib # ls -l a_file.bin
-rw-r--r--    1 root     root      47090160 Dec 12 16:41 a_file.bin

Isso aumentou o arquivo de dados de 299 milhões para 344 milhões. Mas quando removi o a_file.bin (e esperei um pouco), ele voltou para 299M.

Então, isso me parece ser um bug do mapeador de dispositivos. Ou seja, ele encaminha os descartes do dispositivo thinp para o dispositivo subjacente, mas não descarta ao remover dispositivos thinp do pool.

Este parece ser um problema do kernel, eu estava tentando contornar isso usando BLKDISCARD, mas falhei. Veja estes bugs para alguns detalhes: https://bugzilla.redhat.com/show_bug.cgi?id=1043527

Coloquei minha solução alternativa em https://github.com/alexlarsson/docker/tree/blkdiscard , mas ainda estamos pesquisando se podemos fazer melhor do que isso.

Comentários do dm upstream sobre este problema:
http://device-mapper.org/blog/2013/12/17/thin-provisioning-and-discard-support/

Também estou tendo esse problema no CentOS (2.6.32-358.23.2.el6.x86_64) com o Docker 0.7.0. Antigo, mas o problema não é isolado do Ubuntu.

Mesmo problema no Arch GNU / Linux 3.12.6-1-ARCH, Docker versão 0.7.2.

Ainda existe no 0.7.0 no CentOS.

Ainda existe no 0.7.2 no ubuntu 12.04.3 LTS.

Muito do espaço está em docker/devicemapper/devicemapper/data e metadata , mas também em docker/devicemapper/mnt

É legal saber que você pode ver os sistemas de arquivos do contêiner em docker/devicemapper/mnt/SOME_KIND_OF_ID/rootfs

mas não é legal que meu disco rígido esteja quase totalmente consumido e só possa ser corrigido por rmdir -r docker .

Estou tendo um problema semelhante ao escrever o suporte docker para rspec-system. Minha VM de teste (host docker) tem uma unidade de 8 GB e, depois de criar imagens repetidamente sem excluí-las, minha unidade fica cheia. Mas depois de remover todas as imagens e contêineres, a unidade ainda está 100% cheia. Achei que era um erro ID-10T, mas desisti e destruí a VM completamente.

Ainda existe no 0.7.5 no Ubuntu 13.04.

Este problema foi corrigido pelo PR # 3256, que foi recentemente incorporado. Esta correção será incluída em uma versão futura.

Estou encerrando este problema agora porque a correção foi mesclada ao mestre.

Nota: Não é _fulamente_ corrigido até que você execute um kernel com http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= 6d03f6ac888f2cfc9c840db0b965436d32f1816d nele. Sem isso, a correção do docker é apenas parcial.

Qual é a solução alternativa para remover espaço. Estou usando o rhel 6.5 e pode demorar um pouco para obter o novo kernel.

Enviado do meu iPhone

Em 21 de janeiro de 2014, às 6h18, Alexander Larsson [email protected] escreveu:

Nota: Não é totalmente corrigido até que você execute um kernel com http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= 6d03f6ac888f2cfc9c840db0b965436d32f1816d nele. Sem isso, a correção do docker é apenas parcial.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

@logicminds Não existe uma maneira super fácil de recuperar o espaço atm. Tecnicamente, deve ser possível esparsificar manualmente os arquivos de loopback. Mas isso exigiria que todos os blocos não usados ​​fossem zerados ou algo para facilitar a detecção das áreas esparsas, o que não é feito na remoção do dispositivo thinp.

@alexlarsson Isso também afeta o OEL 6.5? O OEL 6.5 realmente usa o kernel do linux uek 3.8 e, como tenho a opção de alternar do kernel 2.6 para o 3.8, essa pode ser uma opção simples para mim.

@logicminds Eu nem sei se esse commit está no kernel upstream ainda. Esse link é da árvore do mapeador de dispositivos. Definitivamente não está no 3.8.

Estou pensando em criar uma ferramenta como o fstrim, que pode ser usada para recuperar o espaço.

O problema https://bugzilla.redhat.com/show_bug.cgi?id=1043527 foi encerrado, oficialmente devido a "dados insuficientes". Isso significa que o patch não entrará no kernel? Ainda é necessário?

@vrvolle O patch que

Ainda tenho esse problema com o docker 0.9 no centos 6.5 com o kernel 2.6.32 padrão.

Não tenho certeza de entender o que você disse anteriormente sobre este commit no mapeador de dispositivos. Você poderia confirmar que se eu migrar meu kernel para o 3.8, esse bug deve ser resolvido?

Desde já, obrigado.

@ nicolas-van Não, você precisa deste commit: https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316

Ele está no 3.14 e pode estar em vários backports 3.xy

Eu instalei há algum tempo o docker para construir uma imagem e executá-la dentro de um contêiner. Então, algum tempo depois, limpei todas as imagens e contêineres, incluindo o aplicativo docker e a pasta principal.
Agora eu percebo que de um total de 4 GB / 24 GB livres / usados ​​(df -h), o comando du / -sh reporta apenas 10 GB, portanto, outros 10 GB não estão sendo contabilizados. Isso é menos o tamanho das imagens temporárias geradas com docker, poderia estar relacionado a este bug. Usei centos 6.5 e docker 0.9.

Eu removi docker com yum e devs de / dev / mapper / docker * com dmsetup, e também rm / var / lib / docker -Rf, e ainda os relatórios de disco com df 10gb usados ​​que não consigo encontrar em lugar nenhum.

@Jacq É possível que algum arquivo ainda seja mantido ativo por um processo que possui um descritor de arquivo aberto. Você reiniciou? Isso garantiria que isso não acontecesse.

Eu executo o Linux 3.14.4-1-ARCH e o docker 0.11.1, removi todas as imagens e contêineres.
e o arquivo / var / lib / docker / devicemapper / devicemapper ficou parado, consumindo cerca de 1,5 GB

aqui está o resultado de depois que eu estava mexendo em algumas coisas do mongodb, acho que o tamanho do arquivo deve ser alocado esparsamente porque meu / var não é nem tão grande.

~/w/e/video_history ❯❯❯ docker info
Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-254:3-585-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 948.4 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 1.0 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.14.4-1-ARCH
WARNING: No swap limit support
~/w/e/video_history ❯❯❯ sudo ls -alh /var/lib/docker/devicemapper/devicemapper/data
-rw------- 1 root root 100G Jun  4 14:35 /var/lib/docker/devicemapper/devicemapper/data
~/w/e/video_history ❯❯❯ sudo  du -shc /var/lib/docker/devicemapper/
1.6G    /var/lib/docker/devicemapper/
1.6G    total

Com licença, o bug foi corrigido agora? Eu o encontrei no gentoo.

@bolasblack Eu

Estou usando as últimas fontes do gentoo que são 3.14.14 para x86_64. Eu olhei em https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316?diff e esse patch é aplicado às minhas fontes. Tenho docker Docker versão 1.1.0, build 79812e3.

@alexlarsson Obrigado por trazer sua atenção de volta para este problema encerrado após um longo período de tempo. Parece que ainda está causando problemas. Alguma palavra sobre o status de # 4202?

Isso ainda é um problema! Acho que vou voltar a usar o AUFS por enquanto.

@daniellockard AUFS parece não oficialmente obsoleto: # 783 e # 4704, então boa sorte com isso.

Caramba ... para onde foram aqueles 25 GB? Oh, naquele arquivo .... Estou executando o kernel 3.16.2 f20 64b

O link para a 'solução alternativa' está quebrado ... o que é? e meu kernel o suporta ... se Torvalds se comprometeu no 3.14, eu suspeito que o fedora deveria ver no 3.16, não?

+1

+1

+1

+1 Ainda parece estar acontecendo no Ubuntu Trusty, 3.13.0-36-generic com Docker versão 1.3.1, build 4e9bbfa

+1 também no Trusty. Vale a pena verificar em 14.10, que usa 3.16?

@SvenDowideit @shykes @vieux @alexlarsson @Zolmeister @creack @crosbymichael @dhrp @ jamtur01 @tianon @erikh @ LK4D4

Etiquetar os principais committers porque isso é ridículo. É preciso haver uma conversa pública sobre isso e uma admissão da equipe do Docker de que esse bug pode levar a contêineres ou sistemas que quebram periodicamente e precisam ser recriados. Eu já conheço várias pessoas que tiveram que implementar soluções de devops insanas, como recriar periodicamente a imagem de seus hosts Docker a cada uma ou duas semanas, porque seus bots de compilação têm muita rotatividade. Eu apresentei esse problema há quase um ano e, pelo que posso dizer, nenhuma solução definitiva foi criada, e kernels mais antigos que são ostensivamente suportados não são.

Equipe do Docker: faça uma pesquisa para determinar quais versões do kernel foram afetadas, por que e qual patch irá corrigir o problema e documente-o. Publique essas informações junto com as versões de kernel que você oferece suporte, porque agora os consumidores do Docker estão sendo mordidos por esse problema continuamente, como evidenciado pelo fato de que eu ainda recebo e-mails sobre esse problema a cada uma ou duas semanas. Sério, este é um problema de quebra e tem sido um problema desde antes de 1.0.

A meu ver, há várias opções possíveis para corrigir esse problema de forma satisfatória, o que interromperia os e-mails que recebo com + 1s sobre esse problema:

1. Notifique os usuários quando o Device-Mapper estiver sendo usado em um kernel não suportado e forneça-lhes instruções detalhadas sobre como recuperar espaço e, se possível, configurar automaticamente um processo para fazer isso no Docker. Aconselho que este aviso também seja emitido ao usar o docker CLI contra um host que sofre desse problema, de modo que, ao gerenciar remotamente os hosts do docker CLI, os usuários fiquem cientes de que alguns hosts podem não recuperar espaço corretamente.
2. Corrija o problema (de alguma forma). Não sei o suficiente sobre o desenvolvimento do kernel para saber o que isso implicaria, mas, com base em minhas leituras de novato, sugiro o seguinte:

uma. Como o mapeador de dispositivo é um módulo do kernel, traga uma versão funcional e funcional dele para a árvore de origem do Docker como algo como dm-docker

b. Faça alterações suficientes em dm-docker que ele possa coexistir com o mapeador de dispositivo.

c. Em plataformas afetadas, instale o módulo dm-docker kernel na instalação e use dm-docker padrão.

1. Corrija seus documentos de instalação e o site docker.com para incluir um aviso sobre as versões afetadas do kernel e adicione uma verificação de tempo de execução aos pacotes para verificar a operação correta do mapeador de dispositivos e, se não, informe ao usuário.

Isso deve ser um problema de bloqueio para a próxima versão estável do Docker, porque é simplesmente inaceitável continuar jogando e deixando os usuários em apuros.

Pessoalmente, vejo o CoreOS como a única distro Linux estável para Docker (até que esse problema seja resolvido).

Equipe Docker: Eu sei que este problema não é causado pelo seu componente, mas por favor, ajude-nos a usar seu software também nas outras distros Linux. Seria ótimo se você também pudesse mencionar esse problema como uma limitação bem conhecida do Docker na documentação, para que outras pessoas não percam seu tempo.

Obrigado!
Martin

+1 algo precisa ser feito.

Seria bom se houvesse algo mais aparente para esse problema do que ter que pesquisar a lista (fechada) de problemas do github. Demorou muito para descobrir que esse era o problema subjacente e teria sido bom ter visibilidade sobre esse problema.

Nós, desenvolvedores de mapeadores de dispositivos upstream (eu e Joe Thornber), tínhamos consciência absolutamente _zero_ de que esse problema ainda é um problema para as pessoas. Corrigimos o problema imediatamente assim que ficamos cientes dele (por http://git.kernel.org/linus/19fa1a6756ed9e9 ( "dm thin: corrige o suporte para descarte em um bloco compartilhado anteriormente")

Joe Thornber acaba de ser informado de que @alexlarsson implementou trim-pool no código docker go. Quando eu indiquei a ele, ele implementou uma ferramenta autônoma adequada 'thin_trim' que será distribuída como parte do pacote 'device-mapper-persistent-data' (pelo menos no Fedora, CentOS, RHEL), consulte:
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

SO ... Dito isso, os usuários que estão executando kernels que não possuem o upstream commit 19fa1a6756ed9e9 ("dm thin: conserta o suporte para descarte em um bloco compartilhado anteriormente") precisam consertar isso executando kernels que são melhor suportados. Posso facilmente enviar uma nota para [email protected] para preencher a correção para quaisquer kernels estáveis ​​que não a tenham. Então, por favor, deixe-me saber qual (s) kernel (s) estável (s) não tem essa correção.

Seguindo em frente, queremos que o docker execute periodicamente o 'thin_trim' no dispositivo de pool fino que o docker está usando. Mas vamos cruzar essa ponte assim que 'thin_trim' estiver amplamente disponível nas distros.

@shabbychef @daniellockard não, os AUFs não estão obsoletos - primeiro, apenas um desses problemas foi encerrado e, continuando a leitura, suponho que https://github.com/docker/docker/issues/783#issuecomment -38731137 é Vale a pena ler:

Our initial plan was to phase out aufs completely because devmapper appeared
 to be the best option in 100% of cases. That turned out not to be true, there 
are tradeoffs depending on your situation and so we are continuing to maintain both.

@snitm você poderia adicionar algo a hack/check_config.sh para dizer aos usuários que seu kernel não tem este patch?

@SvenDowideit infelizmente a mudança em questão não foi identificada em um kernel arbitrário. Para começar, o commit 19fa1a6756ed9e9 não colidiu com a versão dos destinos thin ou thin-pool. Mas mesmo se isso acontecesse, a versão irá variar em todos os kernels estáveis ​​(e é por isso que os picos de versão dentro de um commit 'estável' são ruins .. já que é motivo para edição manual de todos os kernels para os quais o commit é portado).

MAS, todos os usuários que possuem uma versão de destino de thin e pool thin> = 1.12.0 terão a correção. Portanto, kernels> = 3,15. O docker que os usuários estão executando também precisa incluir @alexlarsson 's docker.git commit 0434a2ce ("devmapper: Adicionar opção blkdiscard e desabilitá-la em dispositivos brutos")

Para sua informação, a execução de 'dmsetup targets' listará as versões de destino do thin-pool e thin-pool (desde que o módulo do kernel dm-thin-pool seja carregado).

Obrigado pela atenção sobre isso. Mencionamos isso para os caras do estande no Re: Invent na semana passada.

@snitm então dmsetup targets output deve ser adicionado ao check-config output?

@snitm

Seria possível criar um teste automatizado que criaria um dispositivo mapeador de dispositivos com provisionamento thin, executar algumas operações nele que não recuperariam espaço livre em um kernel sem patch e relatar um código de status baseado nisso?

@SvenDowideit, você espera encontrar novos kernels ofensivos antes que eles comecem a usar o provisionamento thin DM no topo do loopback?

@AaronFriel parece extremamente limitado em escopo por estar tão preso a essa correção específica. A implantação de thin provisioning DM em nível empresarial envolve mais do que garantir que essa correção esteja em vigor (realidade infeliz). O destino de provisionamento thin DM viu numerosos tratamento de erros, desempenho e melhorias de recursos desde que o commit 19fa1a675 foi upstream. Tudo isso é importante ao implementar o provisionamento thin DM na produção.

Portanto, dando um passo para trás, posso gostar de trabalhar para uma empresa que entende que produtos em camadas precisam ser desenvolvidos em conjunto com todas as camadas subjacentes. E tenho pouco interesse em oferecer suporte ao provisionamento thin DM para N kernels arbitrários emparelhados com o docker.

E acontece que eu _fortemente_ acredito que ninguém deveria usar o provisionamento thin DM com dispositivos de loopback como dispositivos de apoio. Foi um hack completo que foi incorporado ao docker sem a devida restrição ou preocupação com "como fica isso na produção?".

Percebi que uma implementação adequada do docker no provisionamento thin DM requer os recursos de gerenciamento orientado para a empresa que a configuração de provisionamento thin baseado em lvm2 fornece. Portanto, com isso em mente, tenho trabalhado constantemente para fazer uma nova solução de gerenciamento híbrido funcionar, veja este PR:
https://github.com/docker/docker/pull/9006

Este trabalho depende de:
1) lvm2> = 2.02.112
2) DM thin-pool target version> = v1.14.0 (também conhecido como mudanças testadas em linux-next para Linux 3.19 inclusão)

RHEL7.1 terá essas alterações. E RHELAH (Atomic Host) também. Quaisquer outras distros / produtos que desejam implantar o docker adequadamente no provisionamento thin DM também devem.

@snitm sim - estou tentando reduzir o número de usuários que são atingidos por uma quebra misteriosa, o que leva ainda mais tempo para alguém perceber que pode ser essa dor obscura, do que tentar pedir ao usuário para descobrir que a falta de algum patch misterioso é o problema.

e assim, no contexto de suas informações restantes - eu quero reduzir o número de kernels que causarão esta surpresa horrível :)

@SvenDowideit OK, forneci a informação que o docker (ou seus usuários) poderia usar para verificar a compatibilidade do DM thinp em loopback neste comentário: https://github.com/docker/docker/issues/3182#issuecomment -63706507

@snitm , @AaronFriel
Estou tendo o que parece ser esse problema no AWS beanstalk, Amazon AMI.
(Ficando sem espaço)
Linux ip-172-31-63-145 3.14.23-22.44.amzn1.x86_64 # 1 SMP Tue Nov 11 23:07:48 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux

versão docker $ sudo
Versão do cliente: 1.3.2
Versão da API do cliente: 1.15
Versão Go (cliente): go1.3.3
Git commit (cliente): c78088f / 1.3.2
OS / Arch (cliente): linux / amd64
Versão do servidor: 1.3.2
Versão API do servidor: 1.15
Versão Go (servidor): go1.3.3
Git commit (servidor): c78088f / 1.3.2

Ainda estou recebendo este erro com Ubuntu 14.04 e Docker 1.4.1.

Não conte com o thin-pool e versões thin sendo> = 1.12.0 para significar que você está bem. Estamos executando VMs CentOS 6.5 com o kernel 2.6.32-431.29.2.el6.x86_64 e relatórios de destinos de dmsetup que thin-pool e thin são ambos v1.12.0. No entanto, estou preso com um arquivo de dados de 40 GB que não está se libertando.

Quais são as implicações ao executar isso no CentOS / RHEL 6.5 com esse bug? Você está bem com> = 100G de espaço livre. Presumo que isso acabe por preencher qualquer tamanho de disco? Ou é limitado a 100G?

Lembre-se de que o 6.5 não tem o kernel mais novo disponível para centos. Eu recomendaria uma simples 'atualização yum' para 6.6 e uma reinicialização para testar com o kernel 2.6.32-504.3.3.

Confirme se as atualizações mais recentes do kernel e da distro para CentOS 6 funcionam bem e liberam espaço.

ripienaar: Você pode indicar explicitamente qual CentOS 6 e versão do kernel você está usando? Só quero ter certeza de que, quando passar as informações adiante, terei todas as informações de que preciso.

obrigado.

Como @reiz comentou acima, isso está acontecendo com o último docker Ubuntu 14.04 +. Os destinos dmsetup mostram thin / thin-pool de v1.9.0 em uma de nossas instâncias (sem contêineres docker ativos). Os destinos dmsetup não mostram nenhuma entrada thin em uma instância semelhante com contêineres docker ativos. (Não estou pedindo ajuda nisso, apenas adicionando dados (espero úteis).

Coisas básicas do sistema operacional:

# uname -a
Linux vagrant-centos65 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
# cat /etc/redhat-release
CentOS release 6.6 (Final)

# dmsetup targets
thin-pool        v1.14.0
thin             v1.14.0
mirror           v1.12.0
striped          v1.5.6
linear           v1.1.0
error            v1.2.0

# dmsetup status
docker-8:1-393542-pool: 0 209715200 thin-pool 92343 178/524288 4664/1638400 - rw discard_passdown queue_if_no_space

Uso:

# du -h /var/lib/docker/
2.7G    /var/lib/docker/devicemapper/devicemapper
# docker rmi b39b81afc8ca
# du -h /var/lib/docker/
2.5G    /var/lib/docker/devicemapper/devicemapper

Antes de entrar naquele kernel, ele não recuperaria espaço.

@jperrin menciona que isso pode ser resolvido usando centos kernel 2.6.32-504.3.3. é conhecido qual commit de kernel (conjunto de commits?) que resolve esse problema?

Atualmente, estou usando um dos Oracle Enterprise Linux 3.8 UEK.

Existe alguma solução alternativa para esta situação? na AWS é fácil apenas recriar a instância, mas no ambiente de desenvolvimento local não é bom notar que a partição / var pertence em 90% ao mapeador de dispositivos por causa do docker; em breve não terá espaço nem para registros ou diários

@donrudo como acima - atualize para o centos 6 mais recente - o kernel 504.3.3.

Isso é bom para centos, mas alguns de nossos desenvolvedores estão usando Fedora e outros OpenSuse.

Todas as alterações de provisionamento thin DM são enviadas primeiro para o upstream. Portanto, se Centos 6 for corrigido, ele também será corrigido no upstream. As várias distros precisam retirar as correções ou rebase de forma mais agressiva.

@ripienaar Vou perguntar de novo, você sabe qual kernel commit (ou conjunto de commits) que são necessários para a correção?

@lexinator não

Estou vendo esse problema no Ubuntu 14.04 Trusty e no kernel 3.13.0-36-generic. A solução possível é anexar o armazenamento do AWS EBS ao diretório para que ele possa escalar indefinidamente.

Gente, esse problema dói muito. O CoreOS está mudando para ext4 agora e em breve teremos todos esses problemas no CoreOS também.

Como as pessoas podem usar o docker (em dev ou prod) enquanto esse problema não foi corrigido por mais de um ano? Todo mundo tem discos infinitos?

Eu acredito que eles estão mudando para ext4 para overlay e não para devmapper. Mas isso é
apenas a palavra na rua ...

Na quarta-feira, 28 de janeiro de 2015, Sergey [email protected] escreveu:

Gente, esse problema dói muito. CoreOS está mudando para ext4 agora e em breve nós
terá todos esses problemas no CoreOS também.

Como as pessoas podem usar o docker (em dev ou prod) enquanto este problema não é corrigido para
mais de um ano? Todo mundo tem discos infinitos?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/3182#issuecomment -71800923.

Estou confuso. Meu espaço em disco em uma instância do Google é de apenas 10G, mas o tamanho de / var / lib / docker / devicemapper / devicemapper / data é mostrado como 100G. Não consigo recuperar espaço, mesmo depois de excluir todos os contêineres e imagens.

É um arquivo esparso. Use ls -sh vez de ls -l ou, alternativamente, du -h

Posso relatar isso no Ubuntu 13.04 (provavelmente não é surpreendente).

A única solução real para isso agora é provisionar espaço em disco suficiente para antecipar o crescimento do mapeador de dispositivos?

Este tópico inteiro é bastante ridículo. Um usuário Debian após o outro reclamando. Se estiver vendo um problema, você deve mudar para uma distribuição com manutenção adequada ou trabalhar com os mantenedores da distro para que eles resolvam o problema. Essas distros não estão acompanhando as correções ou melhorias. Estarei ignorando todos os pedidos futuros para que alguém corrija esse problema na distro $ foo, uma vez que a correção já está claramente no upstream (consulte CentOS ou RHEL). Abra um bug contra a distro quebrada em questão e mencione esse problema.

Não é tão ridículo quando o Docker afirma que tem suporte nas seguintes plataformas:

Docker is supported on the following versions of Ubuntu:

Ubuntu Trusty 14.04 (LTS) (64-bit)
Ubuntu Precise 12.04 (LTS) (64-bit)
Ubuntu Raring 13.04 and Saucy 13.10 (64 bit)

Como você pode ter uma chamada de suporte geral para 14.04 quando este problema é obviamente tão prevalente. O Docker obviamente deve descartar o suporte geral para certos kernels em certas distribuições.

Estou usando o CentOS e a atualização do kernel parece ter melhorado o problema de uso do devicemapper.

De qualquer forma, obrigado pelo seu trabalho @snitm.

Para aqueles que têm esse problema no Ubuntu, certifique-se de limpar adequadamente imagens / contêineres antigos do docker. Descobri que meu script de limpeza não estava sendo executado quando pensei que estava e é por isso que estava usando tanto espaço.

`` `#! / bin / bash

Excluir todos os contêineres

docker rm $ (docker ps -a -q)

Apagar todas as imagens

docker rmi $ (docker imagens -q)
`` `

@TylerMills observe que docker rm _não_ removerá volumes criados pelos contêineres. Se os seus contêineres usam volumes, você deve usar docker rm -v para que o docker remova os volumes também.

@snitm Acabamos de

Observe também que me deparei com esse problema e fiz o seguinte para corrigi-lo:

No meu caso, entretanto, devido ao dispositivo que / var é montado ao atingir 100% de uso, a única maneira de impedir o host de entrar em um kernel panic é matar o processo docker diretamente (ou seja, emitir qualquer comando docker entraria em pânico).

Em seguida, elimine manualmente quaisquer processos usando as montagens do mapeador de dispositivos usando este comando:

grep docker /proc/*/mounts | awk -F/ '{ print $3 }' | xargs kill -9

então eu fui capaz de desmontar qualquer montagem do mapeador de dispositivo usando:

for i in /dev/mapper/docker-*; do umount $i; dmsetup remove $i; done

essas etapas liberaram todos os descritores de arquivo que me permitiram recuperar o espaço / deletar arquivos qualquer coisa.

Nesse ponto, no meu caso, fazia mais sentido mover o diretório / var / lib / docker para uma montagem com mais espaço e configurar o daemon do docker para usar um diretório inicial diferente usando o argumento -g

graças a Alexander Larsson via Adam Miller

Seguindo com o comentário de @dekz , provavelmente seria uma boa idéia se o guia de instalação não instruísse os usuários que as versões do kernel sem esta correção são aceitáveis, como é feito aqui: https://docs.docker.com/installation/ubuntulinux/

Obrigado @JohnMorales. Um pequeno aviso sobre isso do Docker seria uma ótima ideia.

+1

+1

Recentemente, resolvemos executar o Ubuntu 14.04.2 LTS (3.16.0-30-genérico) e ainda estamos lutando para encontrar uma solução. Parece que mudar para o CentOS 6.6 (que supostamente tem a correção do kernel) ou montar um volume que tem um disco maior são as únicas soluções.

Alguém executando o Ubuntu encontrou uma solução aceitável?

Eu concordo - o Docker deve se preparar e resolver esse problema - é um bug sério que precisa de documentação e mensagens de aviso, para que mais pessoas não caiam ingenuamente na mesma armadilha.

Eu concordo com @natea
Estou enfrentando o mesmo problema com o redhat 6.5 e ele está colocando uma grande dúvida se o docker está pronto para produção e estamos começando a procurar alternativas.
Não me importo nem mesmo de obter uma solução alternativa manual para resolver o problema, mas, no momento, não estou ciente de nenhuma viável.

@sagiegurarie esteja ciente de que

então a questão nº 11643 não é relevante? isso significa que não podemos usar o redhat 6.5?

@natea @sagiegurari O que funciona para nós é o "conserto" manual sugerido por @TylerMills

# Delete all containers
docker rm $(docker ps -a -q)
# Delete all images
docker rmi $(docker images -q)

A desvantagem, é claro, é que você precisa puxar novamente todas as imagens e executar os contêineres novamente.

@bkeroackdsc Lembro-me de ter excluído todos os contêineres e imagens antes também e isso não resolveu, mas vou tentar novamente.

Olá! Gostaria de saber se esse problema ainda existe no ubuntu-15.04. Que agora está no kernel linux-3.19. Muito Obrigado.

se você está no ubuntu-15.05 com aquele kernel porque não usar sobreposição, é assim
melhor que o mapeador de dispositivos

Na quinta-feira, 7 de maio de 2015 às 11h26, Dreamcat4 [email protected] escreveu:

Olá! Gostaria de saber se esse problema ainda existe no ubuntu-15.04.
Que agora está no kernel linux-3.19. Muito Obrigado.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99968299.

@jfrazelle Oh certo. Como é? Você usa sobreposição? Eu estava assumindo (até agora) que o suporte de sobreposição ainda era experimental no kernel 3.19.

Sim, eu uso a sobreposição :) esperamos movê-la para cima na lista em 1,7 sem nós
use e ame

Na quinta-feira, 7 de maio de 2015, Dreamcat4 [email protected] escreveu:

@jfrazelle https://github.com/jfrazelle Ah, certo. Como é? Faz
você usa sobreposição? Tenho presumido (até agora) que
o suporte de sobreposição ainda era experimental no kernel 3.19.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99982543.

@sagiegurari Por que você continuaria com o 6.5? Há uma série de atualizações e correções que você está perdendo ao NÃO ir para a versão 6.6, incluindo CVEs com nomes que valem notícias.

@jperrin porque não é minha decisão :)
de qualquer forma, estou tentando verificar com todas as equipes para ver se o redhat 7 está ok para produção.

Este parece ser um problema no CentOS7 (3.10.0-123.el7.x86_64). Eu configurei uma nova caixa CentOS e instalei o docker v1.6.0. O arquivo de dados devicemapper nunca diminui de tamanho após um sudo docker rmi. Estou procurando uma caixa CentOS6.6 para testá-la.

v1.6.0 no Ubuntu 14.04 pareceu ter um efeito positivo (sobre v1.5.0)

parece funcionar bem no centos 7, o que eu acho que também posso dizer para redhat 7
mas redhat 6.5 não é, e sugiro afirmar isso nos documentos.

Isso deve estar funcionando no docker upstream mais recente. E o último comentário de @sagiegurari parece sugerir isso. (funciona no centos 7).

Se for esse o caso, devemos fechar este bug.

Então, esse problema ainda está acontecendo com o docker mais recente? Se não, vamos fechá-lo.

bem ... a execução de mais testes parece fornecer resultados incertos.
vamos dizer que é muito melhor, mas ainda pode estar vazando, apenas muito mais lento.
Vou fazer mais verificações para confirmar.

@sagiegurari

Você pode me dar mais detalhes sobre qual é o problema que você está enfrentando e também sobre o seu ambiente. O título do problema diz que o espaço não é recuperado após a exclusão da imagem / contêiner, e o docker upstream mais recente não deve ter tais problemas.

Você pode pegar o docker upstream, construir um binário dinâmico, criar um novo thin pool (em um diretório / var / lib / docker /), extrair uma imagem, excluí-la e olhar as informações do docker e ver se o espaço foi liberado ou não.

Vou fazer mais testes na próxima semana para fornecer informações mais exatas.

Admito que vejo isso em nossa máquina de compilação, onde criamos e removemos muitas imagens (durante a própria compilação) + executamos o docker registry 2.0 (para o qual sempre enviamos as diferentes imagens com a tag 'mais recente') + executamos alguns contêineres para faça o teste inicial para que tudo funcione bem (o teste não deve ser executado nessa máquina, mas estamos no estágio inicial, então criamos / paramos / rm muitos contêineres).

nossas imagens são muito grandes, às vezes vejo um tamanho virtual acima de 2 gb, então se houver um problema, ele se mostra mais rápido do que com imagens normais que normalmente estão em torno de 400 mg.

de qualquer forma, tentarei executar alguns testes para ver o comportamento e fornecer mais detalhes na próxima semana.

Usando o Docker versão 1.6.0, compilar 4749651 / 1.6.0 no kernel Linux 3.14.35-28.38.amzn1.x86_64

A remoção de imagens diminui o espaço em disco reivindicado pelo docker.

@vbatts

Podemos encerrar esse problema? Não acho que no último docker tenhamos o problema de recuperar o espaço de imagem / contêiner de arquivos oop. Se surgir algo específico, pode-se abrir um novo problema com detalhes específicos.

@rhvgoyal Não vejo razão para apressar e fechar este problema depois de tantas pessoas reclamarem de tantas plataformas / versões.

@sagiegurari

Não sei o que ganhamos mantendo o problema aberto. Eu sei que foi corrigido rio acima. Existem tantos problemas em aberto. As pessoas estão usando-os como painel para anotar as observações.

Acho que manter um problema aberto só faz sentido se houver um problema real reproduzível. Caso contrário, essa lista de problemas continua crescendo e é difícil descobrir em qual deles se concentrar.

Ninguém o impede de adicionar mais dados a este problema depois de obtê-los.

@rhvgoyal a qual tag você está se referindo pelo upstream mais recente?

@rhvgoyal Diga o último commit. Acabei de clonar a última árvore git e testá-la. Isso realmente importa?

Muitos problemas são relatados em versões antigas do docker e kernels antigos. Acho que o primeiro passo deve ser ver se o mesmo problema é visível no docker mais recente e no kernerl relativamente mais recente. Isso nos dá uma ideia se ainda é um problema ou algo que não foi corrigido nas versões anteriores.

Quando alguém voltar e ler no futuro, sim. Queria saber em que versão ele foi corrigido.

Emitimos descartes no caso de dispositivos de loopback. Na verdade, foi feito há muito tempo. Acho que 1.6 deveria ter.

@stanislavb testou com 1.6 e funcionou para ele.

Se você consultar meu primeiro comentário neste problema, verá que também tentei com a v1.6.0 no centos7 e ainda tinha o problema.

@alexDrinkwater

Ok, você consegue reproduzi-lo? Que tipo de thin pool você usou (em cima dos dispositivos de loop?). Você reiniciou o docker ou isso acontece na primeira vez que você inicia o docker?

Em alguns casos, pode acontecer que o docker esteja usando dispositivos de loop e, em seguida, o docker seja reiniciado, pode acontecer que o pool não tenha sido encerrado porque algum dispositivo estava ocupado em algum lugar. Ao reiniciar o docker
encontra o pool já lá e não tem conhecimento de que dispositivos de loopback estão sendo usados ​​e não emite descarte. Eu estou me perguntando se você correu para essa situação?

CentOS 7

Docker versão 1.6.2.el7, compilação c3ca5bb / 1.6.2

Antes da limpeza da imagem

[root<strong i="8">@b2</strong> ~]# docker info
Containers: 1
Images: 320
Storage Driver: devicemapper
 Pool Name: docker-8:2-1076248517-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 10.74 GB
 Data Space Total: 107.4 GB
 Data Space Available: 96.63 GB
 Metadata Space Used: 22.8 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.125 GB
 Udev Sync Supported: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.63-11.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 32
Total Memory: 31.52 GiB

[root<strong i="11">@b2</strong> ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      483443064 13100584 470342480   3% /

Depois de alguns docker rmi

[root<strong i="15">@b2</strong> ~]# docker info
Containers: 1
Images: 143
Storage Driver: devicemapper
 Pool Name: docker-8:2-1076248517-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 7.215 GB
 Data Space Total: 107.4 GB
 Data Space Available: 100.2 GB
 Metadata Space Used: 14.68 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.133 GB
 Udev Sync Supported: true
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.63-11.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 32
Total Memory: 31.52 GiB

[root<strong i="18">@b2</strong> ~]# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda2      483443064 9665924 473777140   2% /

@alexDrinkwater

Ok, agora inicializei uma imagem centos7 e tentei o docker 1.6 e não vejo o problema. Aqui estão as etapas.

[ root @ centos7-generic ~] # versão docker
Versão do cliente: 1.6.0
Versão da API do cliente: 1.18
Versão Go (cliente): go1.4.2
Git commit (cliente): 8aae715 / 1.6.0
OS / Arch (cliente): linux / amd64
Versão do servidor: 1.6.0
Versão API do servidor: 1.18
Versão Go (servidor): go1.4.2
Git commit (servidor): 8aae715 / 1.6.0
OS / Arch (servidor): linux / amd64

Já existe uma imagem importada.

[ root @ centos7-generic ~] # imagens docker
TAG DO REPOSITÓRIO ID DA IMAGEM CRIADA TAMANHO VIRTUAL
docker.io/fedora latest ded7cd95e059 2 semanas atrás 186,5 MB

Aqui está a saída das informações do docker.

root @ centos7-generic ~] # docker info
Recipientes: 0
Imagens: 2
Driver de armazenamento: devicemapper
Nome da piscina: docker-253: 1-50331788-pool
Tamanho do bloco da piscina: 65,54 kB
Sistema de arquivos de backup: xfs
Arquivo de dados: / dev / loop0
Arquivo de metadados: / dev / loop1
Espaço de dados usado: 525,5 MB
Total de espaço de dados: 107,4 GB
Espaço de dados disponível: 20 GB
Espaço de metadados usado: 892,9 kB
Total de espaço de metadados: 2,147 GB
Espaço de metadados disponível: 2,147 GB
Udev Sync Supported: true
Arquivo de loop de dados: / var / lib / docker / devicemapper / devicemapper / data
Arquivo de loop de metadados: / var / lib / docker / devicemapper / devicemapper / metadata
Versão da biblioteca: 1.02.93-RHEL7 (2015-01-28)
Driver de execução: nativo-0.2
Versão do kernel: 3.10.0-229.el7.x86_64
Sistema operacional: CentOS Linux 7 (Core)
CPUs: 2

[ root @ centos7-generic ~] # docker rmi fedora
Sem etiqueta: fedora: mais recente
Excluído: ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4
Excluído: 48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731

[ root @ centos7-generic ~] # docker info
Recipientes: 0
Imagens: 0
Driver de armazenamento: devicemapper
Nome da piscina: docker-253: 1-50331788-pool
Tamanho do bloco da piscina: 65,54 kB
Sistema de arquivos de backup: xfs
Arquivo de dados: / dev / loop0
Arquivo de metadados: / dev / loop1
Espaço de dados usado: 307,2 MB
Total de espaço de dados: 107,4 GB
Espaço de dados disponível: 20,22 GB
Espaço de metadados usado: 733,2 kB
Total de espaço de metadados: 2,147 GB
Espaço de metadados disponível: 2,147 GB
Udev Sync Supported: true
Arquivo de loop de dados: / var / lib / docker / devicemapper / devicemapper / data
Arquivo de loop de metadados: / var / lib / docker / devicemapper / devicemapper / metadata
Versão da biblioteca: 1.02.93-RHEL7 (2015-01-28)
Driver de execução: nativo-0.2
Versão do kernel: 3.10.0-229.el7.x86_64
Sistema operacional: CentOS Linux 7 (Core)
CPUs: 2

Observe que o uso de dados caiu de 525 MB para 307 MB. Portanto, excluir uma imagem me trouxe o espaço de volta.

Ok, esqueci de colar o tamanho do arquivo de loop antes e depois da operação. Aqui está.

• Antes de puxar a imagem.
  $ cd / var / lib / docker / devicemapper / devicemapper
  dados de $ du -h
  Dados de 293 milhões
• Após a extração da imagem
  [ root @ centos7-generic devicemapper] # du -h data
  499 milhões de dados
• Após a exclusão da imagem
  [ root @ centos7-generic devicemapper] # du -h data
  Dados de 293 milhões

Portanto, meu arquivo de loop realmente encolheu após a exclusão da imagem. Acho que é disso que você está reclamando.

@stanislavb

Você está usando arquivos de loop? Eles não são visíveis nas informações do docker. Acho que você está tendo o mesmo problema em que, quando o docker começou, o pool já estava lá.

Você pode verificar o tamanho dos arquivos de backup de loop (/ var / lib / docker / devicemapper / devicemapper / data) e certificar-se de que o arquivo encolhe após a exclusão da imagem. (du -h)

@rhvgoyal
CentOS 7, Docker versão 1.6.2.el7, compilação c3ca5bb / 1.6.2

[root<strong i="7">@b2</strong> ~]# du /var/lib/docker/devicemapper/devicemapper/data
7041272 /var/lib/docker/devicemapper/devicemapper/data
[root<strong i="8">@b2</strong> ~]# docker rmi $(docker images -q)
...
[root<strong i="9">@b2</strong> ~]# du /var/lib/docker/devicemapper/devicemapper/data
5617292 /var/lib/docker/devicemapper/devicemapper/data

@stanislavb

Ok, o tamanho do dispositivo de loop está diminuindo de fato.

Também verifiquei pelo código. Iremos emitir o descarte mesmo se, ao reiniciar, o docker encontrar um thin-pool já lá.

    // By default, don't do blk discard hack on raw devices, its rarely useful and is expensive
    if !foundBlkDiscard && (devices.dataDevice != "" || devices.thinPoolDevice != "") {
            devices.doBlkDiscard = false
    }

Conforme o código acima, os descartes são desabilitados apenas se o usuário for aprovado em um dispositivo de bloco de dados ou em um thin-pool. Como também não passamos, os descartes continuam ativos. É por isso que está funcionando para você.

@alexDrinkwater Agora temos dois pontos de dados fixados em 1.6. Você ainda tem dúvidas em encerrar esta questão.

CentOS 6.6

Docker versão 1.5.0, compilação a8a31ef / 1.5.0

Antes da limpeza da imagem

[root<strong i="8">@b1</strong> ~]# docker info
Containers: 2
Images: 2996
Storage Driver: devicemapper
 Pool Name: docker-8:2-21890120-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 43.24 GB
 Data Space Total: 107.4 GB
 Metadata Space Used: 117.1 MB
 Metadata Space Total: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 2.6.32-504.16.2.el6.x86_64
Operating System: <unknown>
CPUs: 32
Total Memory: 31.33 GiB

[root<strong i="11">@b1</strong> ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      475957304 53995488 397777856  12% /

Tamanho verificado do arquivo de dados em 1929 imagens restantes

[root<strong i="15">@b1</strong> ~]# du -h /var/lib/docker/devicemapper/devicemapper/data
30G /var/lib/docker/devicemapper/devicemapper/data

Depois de alguns docker rmi

[root<strong i="19">@b1</strong> ~]# docker info
Containers: 2
Images: 497
Storage Driver: devicemapper
 Pool Name: docker-8:2-21890120-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 13.39 GB
 Data Space Total: 107.4 GB
 Metadata Space Used: 27.87 MB
 Metadata Space Total: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 2.6.32-504.16.2.el6.x86_64
Operating System: <unknown>
CPUs: 32
Total Memory: 31.33 GiB

[root<strong i="22">@b1</strong> ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      475957304 25606060 426167284   6% /
[root<strong i="23">@b1</strong> ~]# du -h /var/lib/docker/devicemapper/devicemapper/data
13G /var/lib/docker/devicemapper/devicemapper/data

Ok, mesmo no 1.5 ele funciona.

Testei isso em uma nova máquina.

Docker versão 1.6.0, compilação 8aae715 / 1.6.0

Antes de puxar:

/dev/mapper/os-var                             3.9G  750M  2.9G  21% /var

Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-253:3-247472-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 307.2 MB
 Data Space Total: 107.4 GB
 Data Space Available: 3.308 GB
 Metadata Space Used: 733.2 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-123.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.634 GiB

após puxar:

/dev/mapper/os-var                             3.9G  815M  2.9G  23% /var

Containers: 0
Images: 22
Storage Driver: devicemapper
 Pool Name: docker-253:3-247472-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 639.9 MB
 Data Space Total: 107.4 GB
 Data Space Available: 3.24 GB
 Metadata Space Used: 1.438 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.146 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-123.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.634 GiB

remover imagem:

sudo docker rmi 617ef0e7677f
Untagged: docker.io/ghost:latest
Deleted: 617ef0e7677fbff322b8f3af29b9795314a333876d66b49e1ddede15229dccea
Deleted: e68d1ee297168a0b3c3e21ff7a9ab14f7df8edf4525e008fcaf3abc83c731387
Deleted: 4eee85e0d29b6836d3d46ff3b84b0292626df5c8428da0aeeb916d33b6fb7642
Deleted: d0e1169bd5617096df1776902e191f23c07ac0fb5b365c5664fd3d4a554e4c8e
Deleted: e983dda26a2392947fffa4cc37b36251b84bbc74c95ce9c353b80a9c8e63d70f
Deleted: 64b0f4c09fde536675106331c31636f8478ed0cf5c2c7aa274d464216e470b3f
Deleted: c0313e19f503a4770c00250049419a014972ba8f3458524d61b377b8fd289ef0
Deleted: ff1093062f402021a7574b3c40692d2c6dc7aec07d66e17caa6c35df19bad091
Deleted: 37b39063e0c0f3c1a8c90d304ad7ba6b47e14242ff60f6f5d091b280258e0ff3
Deleted: 6e878a0c2422a5496d6bfc5eaf1facbc48f66a8e437fdd7db18d8944b20f7072
Deleted: a10b93053713fb726beaea993bad52b39ca92c5ce6b646dbc7d9cd96016ee9bc
Deleted: 1324d506b72f2a602a8f55c5224708e8ff02dec86b5fe46462a1d73aafb32075
Deleted: 70014f2a472b03d0cfde21d99c601db25f62de1d6c8497cadd6e05743c09d5a1
Deleted: f81216b6a47e2f51c80ff56044a5120d4b8cb76e9ea5990ba08ed073e97fd429
Deleted: 286e04b15dcfe587da0d8b6b359d6ae74c3ef299b868183859508304153ceaca
Deleted: 1dbb5edeebca3ae23a32fcf600015df645a788747553287548ce67126b206ab7
Deleted: 8807133d30b36044c670a06b087b6b61082b660a61fef651f0871283c5505bff
Deleted: 4c0283973ca2335a9ae82168956e4add2e6f2f13fd31e16473d695912e34d974
Deleted: 95d6d696e46933c9d063b5d6328b1a92b988462f1277d74d42bbbdd568efc220
Deleted: 80565b90e8eb693f03cea0411aadb45f21f2bcfe39f6b0fda8cf351eaee1f81b
Deleted: df2a0347c9d081fa05ecb83669dcae5830c67b0676a6d6358218e55d8a45969c
Deleted: 39bb80489af75406073b5364c9c326134015140e1f7976a370a8bd446889e6f8

após excluir:

/dev/mapper/os-var                             3.9G  814M  2.9G  23% /var

Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-253:3-247472-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 307.2 MB
 Data Space Total: 107.4 GB
 Data Space Available: 3.24 GB
 Metadata Space Used: 733.2 kB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.147 GB
 Udev Sync Supported: true
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-123.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 4
Total Memory: 7.634 GiB

Deixe-me saber se você tem mais detalhes sobre minha máquina ou versões etc.

@alexDrinkwater

Parece que você está montando um dispositivo separado em / var. Qual é o sistema de arquivos nesse dispositivo e quais são as opções de montagem?

Você também pode me dar seguimento.

• tabela dmsetup
• status dmsetup
• cat / etc / sysconfig / docker-storage

Você pode tentar o caso mais simples de manter / var no próprio root com o sistema de arquivos xfs. Tentando reduzir um pouco o problema.

@alexDrinkwater

Montei outro disco com partição ext4 em / var / lib / docker para que os arquivos de backup de loopback estejam em ext4 (em vez de xfs) e ainda assim as coisas estão funcionando para mim.

/ dev / vdb1 em / var / lib / docker tipo ext4 (rw, relatime, seclabel, dados = ordenado)

Não tenho certeza do que há de especial na sua configuração.

Para ser específico,

• Antes de puxar
  / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / docker
• Após a extração da imagem
  / dev / vdb1 9.8G 544M 8.7G 6% / var / lib / docker
• Após a exclusão da imagem
  / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / docker

@alexDrinkwater

A outra grande diferença entre sua configuração e minha configuração é a versão do kernel. Estou usando "3.10.0-229.el7.x86_64", enquanto você parece estar usando "3.10.0-123.el7.x86_64". Você pode atualizar seu kernel e tentar.

Obrigado pela ajuda @rhvgoyal. Eu não seria capaz de atualizar o kernel hoje. Mas aqui estão as configurações que você pediu:

/dev/mapper/os-var /var ext3 rw,relatime,data=ordered 0 0

vgdocker-lvdocker: 0 62906368 linear 8:17 2048
os-tmp: 0 8388608 linear 8:2 5244928
os-var: 0 8388608 linear 8:2 13633536
os-swap: 0 5242880 linear 8:2 2048
os-root: 0 8388608 linear 8:2 22022144
docker-253:3-247472-pool: 0 209715200 thin-pool 7:1 7:0 128 32768 1 skip_block_zeroing 

vgdocker-lvdocker: 0 62906368 linear 
os-tmp: 0 8388608 linear 
os-var: 0 8388608 linear 
os-swap: 0 5242880 linear 
os-root: 0 8388608 linear 
docker-253:3-247472-pool: 0 209715200 thin-pool 79 179/524288 4688/1638400 - rw discard_passdown queue_if_no_space 

DOCKER_STORAGE_OPTIONS=

Não tenho opções de armazenamento personalizadas configuradas.

Encontrei. Acho que tem algo a ver com o sistema de arquivos ext3. Eu também posso ver o problema. Tente um sistema de arquivos diferente, digamos ext4 ou xfs e você não enfrentará o problema.

/ dev / vdb1 em / var / lib / docker tipo ext3 (rw, relatime, seclabel, dados = ordenado)

• Antes de puxar a imagem
  [ root @ centos7-generic-2 devicemapper] # du -h data
  Dados de 293 milhões
• Depois de puxar a imagem
  [ root @ centos7-generic-2 devicemapper] # du -h data
  Dados 501M
• Após a remoção da imagem
  [ root @ centos7-generic-2 devicemapper] # du -h data
  Dados 501M

Portanto, por algum motivo, se o arquivo de loopback estiver no sistema de arquivos ext3, ele não funciona. Pode ser que o ext3 seja antigo o suficiente para que os descartes de loop não funcionem nele.

Obrigado, assim que vi que o sistema de arquivos era ext3 pensei que poderia ser isso. Acho que se você conseguisse reproduzir o problema no ext3, poderíamos chamá-lo de encerrado. Será uma boa referência para outras pessoas.

Para referência, meus exemplos de trabalho foram Docker 1.6.2 no sistema de arquivos xfs e Docker 1.6.0 e 1.5.0 no ext4.

@vbatts

Podemos fechar isso. A recuperação de espaço funciona bem no xfs e ext4. ext3 parece ser muito antigo para suportá-lo.

@rhvgoyal @vbatts IIRC , há uma verificação de compatibilidade que verifica o sistema de arquivos subjacente. Talvez devêssemos adicionar um cheque de ext3 se esse for o problema aqui?

editar:
para referência; daemon / graphdriver / overlay / overlay.go # L115

O driver de loop usa fallocate () para abrir um buraco no arquivo quando o descarte chega. A página de manual do Linux de fallocate () verifica se ele não é compatível com ext3.

/ *
Nem todos os sistemas de arquivos suportam FALLOC_FL_PUNCH_HOLE; se um sistema de arquivos não suporta a operação, um erro é retornado. A operação é compatível com pelo menos os seguintes sistemas de arquivos:
* XFS (desde Linux 2.6.38)
* ext4 (desde Linux 3.0)
* Btrfs (desde Linux 3.7)
* tmpfs (desde Linux 3.5)
* /

@thaJeztah

Se alguém quiser executar o docker no ext3, acho que devemos permitir isso. Só que eles não terão suporte para descarte, portanto, o tamanho do arquivo de loop não diminuirá quando a imagem / contêineres forem excluídos.

@rhvgoyal, que tal mostrar isso em docker info ? Semelhante à saída Udev Sync Supported .

@thaJeztah

Já temos uma entrada no docker info "Backing filesystem". Não tenho certeza por que diz extfs em vez de ser preciso sobre ext2 / ext3 / ext4.

Pode ser um aviso no momento da inicialização em logs deve fazer aqui. Algo semelhante a um aviso sobre o uso de dispositivos de loop para thin pool.

@thaJeztah

E acho que devemos fazer isso apenas se muitas pessoas forem impactadas por isso. Caso contrário, estamos apenas criando mais trabalho e código e pode não valer a pena.

a estrutura syscall.Statfs_t , com o campo Type em ext2, ext3 e ext4 retornam 0xef53 , e é isso que estamos usando para detectar a magia do sistema de arquivos.

a estrutura syscall.Statfs_t, com o campo Type em ext2, ext3 e ext4 retornam 0xef53, e é isso que estamos usando para detectar a mágica do sistema de arquivos.

Vadio. Teria sido bom ter essas informações para facilitar a identificação dos problemas relatados.

Acho que devemos fechar isso então?

fechando porque este é um problema com ext3 sendo desatualizado. Use ext4 ou xfs

você acha que isso poderia ser melhor documentado na documentação principal do Docker de alguma forma?

Quer o problema seja com o sistema de arquivos ou não, veja quanta confusão isso gerou em dois problemas recentes.

Obrigado.

voltando ao problema # 9786

@dbabits sim, eu acho que mencionar que o ext3 tem alguns problemas pode valer a pena mencionar na documentação. Ainda não tenho ideia de qual seria um local apropriado.

Tem o mesmo problema / semelhante com o XFS.
Estava no kernel "3.10.0-123.el7.x86_64", mas atualizado agora em "3.10.0-229.el7.x86_64".

Tudo é excluído (contêiner, imagens), mas os dados ainda contêm 100 GB.
Alguma ideia, ajuda?

[ root @ docker0101 ~] # ls -alh / data / docker / devicemapper / devicemapper /
total 80G
drwx ------ 2 root root 32 Jun 8 16:48.
drwx ------ 5 root root 50 Jun 9 07:16 ..
-rw ------- 1 root root 100G 16 de julho 21:33 dados
-rw ------- 1 root root 2.0G 17 de julho 09:20 metadados

[ root @ docker0101 ~] # uname -a
Linux docker0101 3.10.0-229.7.2.el7.x86_64 # 1 SMP Ter 23 de junho 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

[ root @ docker0101 ~] # cat / etc / redhat-release
CentOS Linux versão 7.1.1503 (Core)

[ root @ docker0101 ~] # docker ps -a
COMANDO DE IMAGEM DE ID DE CONTÊINER CRIADO NOMES DE PORTOS DE STATUS

[ root @ docker0101 ~] # imagens docker -a
TAG DO REPOSITÓRIO ID DA IMAGEM CRIADA TAMANHO VIRTUAL

[ root @ docker0101 ~] # informações do docker
Recipientes: 0
Imagens: 0
Driver de armazenamento: devicemapper
Nome da piscina: docker-253: 0-268599424-pool
Tamanho do bloco da piscina: 65,54 kB
Sistema de arquivos de backup: xfs
Arquivo de dados: / dev / loop0
Arquivo de metadados: / dev / loop1
Espaço de dados usado: 85,61 GB
Total de espaço de dados: 107,4 GB
Espaço de dados disponível: 40,91 MB
Espaço de metadados usado: 211,4 MB
Total de espaço de metadados: 2,147 GB
Espaço de metadados disponível: 40,91 MB
Udev Sync Supported: true
Arquivo de loop de dados: / data / docker / devicemapper / devicemapper / data
Arquivo de loop de metadados: / data / docker / devicemapper / devicemapper / metadata
Versão da biblioteca: 1.02.93-RHEL7 (2015-01-28)
Driver de execução: nativo-0.2
Versão do kernel: 3.10.0-229.7.2.el7.x86_64
Sistema operacional: CentOS Linux 7 (Core)
CPUs: 4
Memória total: 11,58 GiB
Nome: docker0101

[ root @ docker0101 ~] # tabela dmsetup
vg1-lvol0: 0 167772160 linear 8:16 2048
docker-253: 0-268599424-pool: 0 209715200 thin-pool 7: 1 7: 0 128 32768 1 skip_block_zeroing

[ root @ docker0101 ~] # status do dmsetup
vg1-lvol0: 0 167772160 linear
docker-253: 0-268599424-pool: 0 209715200 thin-pool 71359 51606/524288 1306264/1638400 - ro discard_passdown queue_if_no_space

[ root @ docker0101 ~] # cat / etc / sysconfig / docker-storage
DOCKER_STORAGE_OPTIONS =

[ root @ docker0101 ~] # rpm -qi docker
Nome: docker
Versão: 1.6.2
Lançamento: 14.el7.centos
Arquitetura: x86_64
Data de instalação: Sex, 17 de julho de 2015 09:19:54 CEST
Grupo: Não Especificado
Tamanho: 33825026
Licença: ASL 2.0
Assinatura: RSA / SHA256, Quarta, 24 de junho de 2015 05:43:12 CEST, ID da chave 24c6a8a7f4a80eb5
Fonte RPM: docker-1.6.2-14.el7.centos.src.rpm
Data da versão: Quarta, 24 de junho de 2015 03:52:32 CEST
Build Host: worker1.bsys.centos.org

[root @ docker0101 ~] # ls -al / var / lib / docker
lrwxrwxrwx 1 root root 12 Jun 09 08:21 / var / lib / docker -> / data / docker

[ root @ docker0101 ~] # montagem
/ dev / sda5 em / var tipo xfs (rw, relatime, attr2, inode64, noquota)
/ dev / mapper / vg1-lvol0 on / tipo de dados xfs (rw, relatime, attr2, inode64, noquota)

@tomlux O modo de loopback do mapeador de dispositivos que você está usando é principalmente uma forma de brincar facilmente com o docker. para trabalhos sérios, o loopback será mais lento e terá algumas limitações. Eu recomendo fortemente uma leitura sobre http://www.projectatomic.io/docs/docker-storage-recommendation/

Você obterá melhor desempenho e não atingirá coisas como essa, presumindo que aplicou todas as atualizações do sistema.

@tomlux

você pode adicionar "-s" a ls. Isso lhe dará blocos reais alocados para arquivos de dados e metadados. No momento, ele está mostrando o tamanho aparente dos arquivos.

A saída de informações do docker é intrigante. Parece mostrar alto uso.

@tomlux

Portanto, o tamanho real dos arquivos de dados e metadados parece pequeno. Você pode usar "ls -alsh" para que os tamanhos sejam mais legíveis.

Portanto, o tamanho do arquivo de dados parece ser de cerca de 79 MB e o tamanho do arquivo de metadados é de cerca de 202 KB.

Acho que as estatísticas do thin pool sobre o número de blocos usados ​​não parecem corretas. A reinicialização da máquina corrige o problema?

Reinicializei após a atualização do kernel sem sucesso.

Ok, então os arquivos de loop são grandes e o pool acha que tem muitos blocos usados. Então, algo está usando esses blocos. Você pode me dar a saída de.

• docker ps -a
• imagens docker
• ls / var / lib / dokcer / devicemapper / metadata / | wc -l
• desligue o docker e execute o seguinte.
  thin_dump / var / lib / docker / devicemapper / devicemapper / metadata | grep "device dev_id" | wc -l

Isso dirá quantos dispositivos thin existem no pool.

Hmm,
agora temos contêineres DEAD, mas sem imagens.
Já reiniciei.

Parece haver algo errado com o mapeador de dispositivos.
Não quero enviar spam para esse problema.
Também posso "rm -f / var / lib / docker" e reconstruir meus contêineres. Tudo está programado.

faça "dmsetup status"

Parece que a piscina está em mau estado e provavelmente precisa de reparos.

Oi,

Eu parecia ter o mesmo problema no Ubuntu 14.04. No entanto, a causa foram os volumes indesejados (cf. blog http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/). Executando o comando

docker run -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker:/var/lib/docker --rm martin/docker-cleanup-volumes

liberou muito espaço em disco.

Isso não é corrigido de forma significativa. Em uma instalação do Ubuntu 14.04.x ​​totalmente atualizada (a última versão do LTS) e com a versão mais recente do Docker (instalada via $ wget -qO- https://get.docker.com/ | sh ), o Docker vazará continuamente espaço sem uma maneira fácil de recuperar. docker stop $(docker ps -q) && docker rm $(docker ps -q -a) && docker rmi $(docker images -q) apenas libera uma pequena quantidade de espaço.

A única maneira de recuperar todo o espaço é com o seguinte hack:

$ sudo service docker stop
$ sudo rm -rf /var/lib/docker
$ sudo service docker start

O que então requer puxar novamente todas as imagens de que você pode precisar.

@bkeroackdsc esse espaço também poderia estar relacionado a volumes "órfãos"?

Concordo com @bkeroackdsc isso não está resolvido.
Perguntei a @rhvgoyal por que ele queria tanto encerrar este caso.
no final, caí do docker especificamente por causa desse problema.
está matando este produto.

órfãos ou não órfãos, não existe uma maneira boa e fácil de limpar o espaço.
deve haver uma opção docker cli para limpeza, uma opção de bom relatório de status cli e também algum tipo de monitoramento do espaço em disco, pois esse problema acontece com muitas pessoas em muitas plataformas.

@bkeroackdsc @sagiegurari

A razão pela qual estou perguntando é que os volumes órfãos não estão relacionados a esse problema,
não relacionado ao mapeador de dispositivos.

Volumes órfãos não são
para um contêiner são excluídos automaticamente quando o contêiner é excluído.
_Não_ é o caso (e por design), porque os volumes podem conter dados
que deve persistir após a exclusão de um contêiner.

_Para deletar um volume junto com um container_, use docker rm -v [mycontainer] .
As funções de gerenciamento de volume serão adicionadas (consulte https://github.com/docker/docker/pull/14242 e https://github.com/docker/docker/issues/8363),
e permitirá que você gerencie volumes "órfãos".

Um tamanho crescente de /var/lib/docker não precisa ser uma indicação
que o mapeador de dispositivos está vazando dados, porque um aumento no tamanho desse diretório
também pode ser o resultado de volumes (órfãos) que não foram limpos
pelo usuário (o docker armazena todos os seus dados nesse caminho).

Eu realmente espero que esses 2 itens forneçam os recursos necessários.
Eu entendi o segundo item, mas o primeiro (# 14242), não explica na parte superior do que se trata, além de ser uma api de volume (ou seja, não tenho certeza de quais recursos ele oferece).

@sagiegurari faz parte dos requisitos para implementar o gerenciamento de volume de imagem (existem alguns outros problemas de relações públicas abertas). O objetivo final é fazer com que os volumes sejam cidadãos de primeira classe no Docker, que podem ser criados / excluídos / gerenciados separadamente dos contêineres que os utilizam.

@swachter Obrigado por postar essa solução alternativa,

corrigimos o problema de vazamento de volume com um hack sujo, uma vez que estava impedindo o daemon do docker de inicializar antes que o tempo do serviço se esgotasse em nossos hosts docker de alta rotatividade:

PRODUCTION [[email protected] ~]$ cat /etc/systemd/system/docker.service.d/docker-high-churn.conf 
[Service]
ExecStartPre=-/bin/rm -rf /var/lib/docker/containers
ExecStopPost=-/bin/rm -rf /var/lib/docker/volumes

que corrige o problema sem liberar as imagens pré-armazenadas em cache.

Podemos discutir a questão dos volumes com vazamento em uma edição separada. Discutir isso aqui dá a impressão de que é um problema do mapeador de dispositivos, embora não seja.

@tomlux @rhvgoyal

Você já chegou a uma conclusão sobre o que está acontecendo na caixa do CentOS 7? Meu host docker é quase idêntico e eu estava tendo o mesmo problema. Continuei até o ponto em que thin_dump . Depois, fui iniciar o daemon do docker e ele não começou. Acabei de deletar / var / lib / docker e reiniciei desde então, mas só queria saber se uma resolução foi encontrada, pois eu (e outros) posso encontrá-la novamente.

[root<strong i="11">@Docker_Sandbox_00</strong> devicemapper]# thin_dump /var/lib/docker/devicemapper/devicemapper/metadata | grep "device dev_id" | wc -l
102

[root<strong i="14">@Docker_Sandbox_00</strong> devicemapper]# systemctl start docker
Job for docker.service failed. See 'systemctl status docker.service' and 'journalctl -xn' for details.
 [root<strong i="15">@Docker_Sandbox_00</strong> devicemapper]# systemctl -l status docker.service
docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled)
   Active: failed (Result: exit-code) since Tue 2015-10-27 08:24:47 PDT; 37s ago
     Docs: https://docs.docker.com
  Process: 45244 ExecStart=/usr/bin/docker daemon -H fd:// (code=exited, status=1/FAILURE)
 Main PID: 45244 (code=exited, status=1/FAILURE)

Oct 27 08:24:45 Docker_Sandbox_00 systemd[1]: Starting Docker Application Container Engine...
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.512617474-07:00" level=info msg="[graphdriver] using prior storage driver \"devicemapper\""
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.526637164-07:00" level=info msg="Option DefaultDriver: bridge"
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.526719113-07:00" level=info msg="Option DefaultNetwork: bridge"
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.589016574-07:00" level=warning msg="Running modprobe bridge nf_nat br_netfilter failed with message: modprobe: WARNING: Module br_netfilter not found.\n, error: exit status 1"
Oct 27 08:24:46 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:46.625324632-07:00" level=info msg="Firewalld running: true"
Oct 27 08:24:47 Docker_Sandbox_00 docker[45244]: time="2015-10-27T08:24:47.142468904-07:00" level=fatal msg="Error starting daemon: Unable to open the database file: unable to open database file"
Oct 27 08:24:47 Docker_Sandbox_00 systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE
Oct 27 08:24:47 Docker_Sandbox_00 systemd[1]: Failed to start Docker Application Container Engine.
Oct 27 08:24:47 Docker_Sandbox_00 systemd[1]: Unit docker.service entered failed state.

[root<strong i="18">@Docker_Sandbox_00</strong> devicemapper]# df -ah
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/vdb1                                    20G   20G   24K 100% /var/lib/docker
[root<strong i="19">@Docker_Sandbox_00</strong> devicemapper]# du -sh /var/lib/docker/devicemapper/devicemapper/data
20G     /var/lib/docker/devicemapper/devicemapper/data

@tomlux @rhvgoyal

Eu encontrei a origem do meu problema. Apesar de como parecia, não estava relacionado aos problemas do tópico. Isso se deve a um mal-entendido sobre o funcionamento do docker. Todos, os contêineres mortos ainda estavam segurando o espaço em disco que haviam alocado durante sua execução. Eu só tive que remover todas as carcaças do contêiner para liberar espaço em disco. Eu me lembro disso neste tópico, mas pensei que isso é considerado apenas volumes montados, não o espaço em disco alocado pelo contêiner.

# Beware this removes ALL containers
docker rm -f $(docker ps -aq) 

@tomlux Este pode ter sido o seu problema também, já que sua saída de docker ps -a mostrou vários recipientes Dead .

docker rm não está liberando espaço em disco do contêiner

boot2docker recente no OS X VirtualBox. OS X totalmente corrigido.

Estou construindo um contêiner grande (47 GB) e há um problema indicando que devo reconstruí-lo. Então parei o contêiner e fiz docker rm. Verificação dupla usando docker ssh'df -h', acho que o uso do disco ainda é de 47 GB. O contêiner possui 75 GB.

Então, vou precisar matar a VM do docker novamente.

Podemos fazer isso?

@ awolfe-silversky é espaço em disco _dentro_ que a VM retornou? Se estiver fora da VM, isso pode não estar relacionado.

@ awolfe-silversky também; você removeu a _imagem_ também? remover apenas o contêiner pode não ajudar muito se a imagem ainda estiver lá

@ awolfe-silversky esse problema é sobre o devicemapper - e se você estiver usando docker-machine / boot2docker, é muito mais provável que esteja executando aufs . Também me pergunto se você docker rmi 'd sua imagem grande.

vale a pena executar docker images e docker info para ver se as coisas estão realmente tão terríveis quanto você faz parecer :)

(sim, se você ainda tem o vm e a imagem foi removida, então devemos abrir um novo problema e depurar mais, já que você encontrou um caso estranho)

Eu não removi a imagem. É de um registro docker interno.
Usei um script awk para dimensionar as imagens - total de 6,9 ​​GB.

docker images -a | awk '(FNR > 1) { imgSpace = imgSpace + $(NF - 1); }
END { print "Image space is " imgSpace; }'
Image space is 6909.01

Está sujo, mas sei que todos os tamanhos de imagem estão em MB.

Veja como eu estava tentando diagnosticar o uso:

 file:///Andrew-Wolfe-MacBook-Pro.local/Users/awolfe/DataStores
awolfe_10063: docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

 file:///Andrew-Wolfe-MacBook-Pro.local/Users/awolfe/DataStores
awolfe_10064: docker-machine ssh 'awolfe-dbhost' 'df -h'
Filesystem                Size      Used Available Use% Mounted on
tmpfs                     7.0G    123.8M      6.9G   2% /
tmpfs                     3.9G         0      3.9G   0% /dev/shm
/dev/sda1                71.0G     47.2G     20.2G  70% /mnt/sda1
cgroup                    3.9G         0      3.9G   0% /sys/fs/cgroup
none                    464.8G    379.9G     84.8G  82% /Users
/dev/sda1                71.0G     47.2G     20.2G  70% /mnt/sda1/var/lib/docker/aufs

No momento tenho caixa com 0 imagens.
docker volume ls -qf dangling=true não mostra nada.
docker volume ls mostra muitos volumes, que são, por definição, órfãos, já que não há imagens para possuí-los.
docker volume rm $(docker volume ls) mostra muitas dessas mensagens:

Error response from daemon: get local: no such volume
Error response from daemon: Conflict: remove 6989acc79fd53d26e3d4668117a7cb6fbd2998e6214d5c4843ee9fceda66fb14: volume is in use - [77e0eddb05f2b53e22cca97aa8bdcd51620c94acd2020b04b779e485c7563c57]

O diretório do mapeador de dispositivos consome até 30 GiG.
Docker versão 1.10.2, compilação c3959b1
CentOS 7, 3.10.0-327.10.1.el7.x86_64

Data Space Used: 33.33 GB
 Data Space Total: 107.4 GB
 Data Space Available: 915.5 MB
 Metadata Space Used: 247 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 915.5 MB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.107-RHEL7 (2015-12-01)

Além disso, por que a instalação padrão usa a opção de armazenamento 'fortemente desencorajada'?
Por que não fui avisado na instalação?

Tenho exatamente o mesmo problema aqui em uma instância do Amazon Linux EC2.

Linux ip-172-31-25-154 4.4.5-15.26.amzn1.x86_64 #1 SMP Wed Mar 16 17:15:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Nos casos em que instalo novas imagens do docker regularmente, a única solução é fazer o seguinte:

service docker stop
yum remove docker -y
rm -rf /var/lib/docker
yum install docker -y
service docker start

Eu realmente não acho que tal coisa seja aceitável em um ambiente de produção

algumas informações extras:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G   20G     0 100% /

Como esse bug existe há anos e parece que ainda não foi fechado, você poderia colocar na documentação do docker sobre o devidemapper como destruir a segurança de todas as informações do docker?
quero dizer, nesta página: https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
coloque algo como "Mapeador de dispositivos de limpeza" e como fazer isso.

Vou tentar fazer rm -rf / var / lib / docker, mas não me sinto confortável fazendo isso. Alguém pode me dizer se é seguro?

Estou usando o gentoo linux no meu laptop diário e tentei o docker para aprender, mas estou enchendo meu disco e reinstalar todo o sistema não é uma opção porque não é uma VM e reinstalar o gentoo leva tempo.

Obrigado por seu trabalho.

@mercuriete Em sua máquina de desenvolvimento, desinstale o docker, exclua o diretório e reinstale-o. Funciona bem.

@ ir-fuel: Acabei de fazer isso e agora tenho este:

$ sudo service docker-engine start
Redirecting to /bin/systemctl start  docker-engine.service
Failed to start docker-engine.service: Unit docker-engine.service failed to load: No such file or directory.
$ uname -a
Linux CentOS7 3.10.0-327.18.2.el7.x86_64 #1 SMP Thu May 12 11:03:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Estou usando service docker start

@ ir-fuel obrigado, funciona bem. : +1:

Reinstalar o docker para liberar espaço em disco é a resposta mais ridícula que encontrei ao procurar uma solução para esse problema. Não só isso é uma perda de tempo, como também não é permitido na maioria dos ambientes. É uma boa maneira de receber o pagamento se você trabalha por hora.

Eu concordo completamente. É incrível que um produto como o Docker continue comendo espaço em disco sem nada que você possa fazer a respeito, exceto desinstalar / reinstalar.

Verifique este problema mais uma vez para ver que nada mudou. +1

Este problema está marcado como fechado. Precisamos de uma resolução. Sem solução alternativa, sem reconfiguração. Qual é o status real e quais são as definições de configuração implicadas? Eliminar e recriar um nó Docker de produção não é aceitável.

E qual é a alternativa? Como podemos evitar isso?

Se este não é um recurso recomendado para uso - por que é silencioso e padrão
1? Se você não se importa com as pessoas que usam o mapeador de dispositivos - posso estar até ok
com isso. Mas informe o usuário sobre isso! Você percebe a quantidade de
as pessoas têm dor de cabeça devido a essa incrível 'solução' que você escolheu ??
Em 23 de junho de 2016, 4:32 pm, "kpande" [email protected] escreveu:

a solução alternativa é evitar o uso do driver docker device-mapper,
infelizmente.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397 ou mudo
o segmento
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Sempre há rkt ...

o sarcasmo vulgar vil e inútil é, sem dúvida, por que ninguém do rio acima se importa em lhe dar as respostas adequadas.

ninguém forçou você a usar o Docker.

É como o Oracle dizendo a um desenvolvedor Java para usar PHP devido a um bug do JVM. Isso também não é consistente com o argumento de venda aqui

Três anos atrás, Docker tornou uma tecnologia de kernel Linux esotérica chamada containerização simples e acessível a todos.

Tenho certeza de que muitas pessoas estão gratas pelo Docker ter decolado dessa forma e isso não poderia ter acontecido sem o voluntariado da comunidade. No entanto, não deveria ser tão difícil admitir que ele tem seus problemas também sem deixar cair implicitamente a linha "Sou um contribuidor original, então cale a boca e ouça" sempre que alguém menciona um ponto desagradável.

Esperar. Eu relatei um problema, forneci os detalhes da minha máquina e configuração,
ao qual não sou obrigado. Nenhum dos devteam respondeu ao bug meu e dos outros
relatórios em um semestre. Agora que declarei esse fato, você chama meu comportamento
vadia? Você ao menos abre o código? Estou procurando um projeto Go para trabalhar e
não será Docker, admito. Este é o seu objetivo?
Em 23 de junho de 2016 16:45, "gregory grey" [email protected] escreveu:

Se este não é um recurso recomendado para uso - por que é silencioso e padrão
1? Se você não se importa com as pessoas que usam o mapeador de dispositivos - posso estar até ok
com isso. Mas informe o usuário sobre isso! Você percebe a quantidade de
as pessoas têm dor de cabeça devido a essa incrível 'solução' que você escolheu ??
Em 23 de junho de 2016, 4:32 pm, "kpande" [email protected] escreveu:

a solução alternativa é evitar o uso do driver docker device-mapper,
infelizmente.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397,
ou silenciar o tópico
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Em primeiro lugar, se você ainda tiver esse problema, abra um novo problema;

Esperar. Eu relatei um problema

Você respondeu em um problema fechado de 3 anos; seguindo a discussão acima, o problema original foi resolvido. Seu problema _pode_ ser o mesmo, mas precisa de mais pesquisas para ter certeza; os erros que você está relatando indicam que, na verdade, pode ser outra coisa.

Eu realmente recomendo abrir um novo problema, não comentar sobre um problema fechado

forneceu os detalhes da minha máquina e configuração, que não sou obrigado.

Você não está _obrigado_, mas sem nenhuma informação para prosseguir, é improvável que seja resolvido. Portanto, ao relatar um bug, inclua as informações solicitadas no modelo:
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

Nenhum dos devteam respondeu aos meus e aos outros relatórios de bug em um período de meio ano.

Se você quer dizer "um dos mantenedores", lembre-se de que há quase 24.000 questões e PRs, e menos de 20 mantenedores , muitos dos quais fazendo isso além de seu trabalho diário. Nem todos os comentários serão notados, especialmente se for sobre um problema encerrado.

Se este não é um recurso recomendado para uso - por que é silencioso e padrão?

É o padrão se _aufs_, _btrfs_ e _zfs_ não são suportados, você pode encontrar a prioridade que é usada ao selecionar os drivers; veja daemon / graphdriver / driver_linux.go . Ainda está acima da sobreposição, porque infelizmente ainda existem alguns problemas com esse driver que _algumas_ pessoas podem ser afetadas.

Selecionar automaticamente um driver gráfico serve apenas para "fazer as coisas funcionarem"; o melhor driver para _sua_ situação depende de _seu_ caso de uso. O Docker não pode tomar essa decisão automaticamente, então cabe ao usuário configurar.

Se você não se importa com as pessoas que usam o mapeador de dispositivos - posso até concordar com isso.

Lendo novamente a discussão acima, vejo que os mantenedores do mapeador de dispositivos upstream examinaram isso _múltiplas vezes_, tentando ajudar os usuários a relatar esses problemas e resolvê-los. O problema foi resolvido para aqueles que o relataram ou, em alguns casos, dependia de distros atualizando as versões do devicemapper. Não acho que isso possa ser considerado "não se importar".

Além disso, por que a instalação padrão usa a opção de armazenamento 'fortemente desencorajada'?

Executar em dispositivos de loop é bom para colocar o docker em execução e, atualmente, é a única maneira de configurar o mapeador de dispositivos automaticamente. Para produção e para obter um melhor desempenho geral, use direct-lvm, conforme explicado na seção devicemapper no guia do usuário do driver de armazenamento.

Por que não fui avisado na instalação?

Isso está fora do escopo da instalação, na verdade. Se você for usar algum software em produção, deve ser razoável supor que você se familiarizou com esse software e sabe o que é necessário para configurá-lo para seu caso de uso. Alguns mantenedores até discutiram se o aviso deveria ser exibido. O Linux não é um sistema operacional de "mãos dadas" (sua distribuição mostra um aviso de que pode ocorrer perda de dados se você estiver usando RAID-0? Se você tiver portas abertas em seu Firewall?)

Por mais relutante que eu seja em ressuscitar mais uma vez esse fio antigo, ainda não há nenhum conselho significativo nele sobre como contornar esse problema em uma máquina existente que está encontrando esse problema.

Este é o meu melhor esforço em um tldr; para todo o tópico; Espero que ajude outras pessoas que encontrarem este tópico.

Problema encontrado

Seu volume tem uma quantidade significativa (e crescente) de espaço que está em /var/lib/docker e você está usando ext3.

Resolução

Você não está com sorte. Atualize seu sistema de arquivos ou veja blowing docker away na parte inferior.

Problema encontrado

Seu volume tem uma quantidade significativa (e crescente) de espaço que está em /var/lib/docker e você _não_ está usando ext3 (por exemplo, sistema atualmente usando xfs ou ext4)

Resolução

Você pode recuperar espaço em seu dispositivo usando os comandos padrão do docker.

Leia http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/

Execute estes comandos:

docker volume ls
docker ps
docker images

Se você não tiver nada listado em nenhum desses, consulte blowing docker away na parte inferior.

Se você vir imagens desatualizadas, contêineres não usados, etc., pode realizar a limpeza manual com:

# Delete 'exited' containers
docker rm -v $(docker ps -a -q -f status=exited)

# Delete 'dangling' images
docker rmi $(docker images -f "dangling=true" -q)

# Delete 'dangling' volumes
docker volume rm $(docker volume ls -qf dangling=true)

Isso deve recuperar muito do espaço oculto do contêiner no mapeador de dispositivos.

Soprando docker

Não funcionou? Você não está com sorte.

Sua melhor aposta neste ponto é:

service docker stop
rm -rf /var/lib/docker
service docker start

Isso destruirá todas as imagens do docker. Certifique-se de exportar aqueles que deseja manter _antes_ de fazer isso.

Por fim, leia https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-production; mas espero que isso ajude outras pessoas que encontrarem este tópico.

Se você tiver problemas para usar o conselho acima, abra um novo tíquete que trate especificamente do problema que você encontrou e crie um link para esse problema; não poste aqui.

rm -rf / var / lib / docker

Você também pode usar nuke-graph-directory.sh .

Depois de remover os arquivos conforme declarado acima, não consigo mais iniciar o Docker:
02 de março 04:53:40 pmdc001b dockerd [29522]: Erro ao iniciar o daemon: erro ao inicializar o driver do gráfico: open / var / lib / docker / devicemapper / devicemapper / data: nenhum arquivo ou diretório.

Acabei de encontrar esse problema no CentOS 7.3 e não queria depurar problemas de devmapper que existem por mais de 3 anos, então segui este guia DC / OS, limpei os pacotes originais, mudei para overlayfs e tudo parece funcionar bem agora : https://dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/ (teve que modificar o comando ExecStart para docker versão 17.03 embora -> "dockerd --storage-driver = overlay ")

Server Version: 17.03.0-ce
Storage Driver: overlay
 Backing Filesystem: extfs
 Supports d_type: true
...
Operating System: CentOS Linux 7 (Core)

(limpar volumes, imagens e contêineres não ajudou. Excluir coisas em / var / lib / docker levava ao problema descrito por @ gdring2 )

Executar docker system prune liberou muito espaço em minhas máquinas.

https://docs.docker.com/engine/reference/commandline/system_prune/

Bem, isso é meio ... chato.

No meu caso, encontrei esse problema depois de desinstalar o Docker e excluir o diretório /var/lib/docker , então não pude executar o equivalente a service docker stop ... service docker start .

Descobri que meu sistema não estava relatando o espaço de exclusão de /var/lib/docker como liberado (eu tinha cerca de 14 GB sentado no que parecia ser um limbo).

A solução para isso é simplesmente recarregar o sistema de arquivos, no meu caso, apenas reiniciei e o espaço foi recuperado.

Não acredito que ainda seja um problema! vamos lá pessoal, ainda estou tendo isso

@ shahaf600 qual versão do docker você está executando? Veja também meu comentário acima; https://github.com/moby/moby/issues/3182#issuecomment -228298975

Sem detalhes, não há muito a dizer sobre sua situação; seu caso pode ser causado por um problema diferente, mas resultando em um resultado semelhante.

Boa

depois de comprar um desses pedaços de lixo e ver o estado de suporte, devolvi.

Aí está seu primeiro problema @misterbigstuff ... você comprou algo que é de código aberto?

e devolveu