+1, estoy muy interesado en escuchar alguna discusión sobre este tema. Mi estrategia hasta ahora ha sido

• tenga cuidado con lo que construye / tira
• prepárate para volar tu / var / lib / docker: neutral_face:

@AaronFriel , ¿en qué versión de Docker estás? 0.7.1?

/ cc @regilero (enlace también en # 2276)

A partir de un nuevo / var / lib / docker:

# 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

Luego, después de docker pull busybox, creció un poco:

# 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 _no_ agranda el archivo, pero libera espacio en el grupo de devicemapper:

# 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

El archivo de loopback no crece si volvemos a descargar la imagen:

# 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

Entonces, parece que no logramos volver a esparcir el archivo de loopback cuando el dispositivo thinp descarta un bloque.

Sin embargo, si creo un archivo dentro de la imagen de fs del contenedor, _reclama el espacio en el archivo de loopback.
Es decir, hice esto en la imagen de 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

Esto aumentó el archivo de datos de 299M a 344M. Pero cuando eliminé a_file.bin (y esperé un poco) volvió a 299M.

Entonces, esto me parece que es un error de devicemapper. Es decir, reenvía los descartes del dispositivo delgado al dispositivo subyacente, pero no se descarta cuando se eliminan los dispositivos delgados del grupo.

Esto parece ser un problema del kernel, estaba buscando solucionarlo pero usando BLKDISCARD, pero fallé. Vea estos errores para obtener algunos detalles: https://bugzilla.redhat.com/show_bug.cgi?id=1043527

Puse mi solución en https://github.com/alexlarsson/docker/tree/blkdiscard , pero todavía estamos investigando si podemos hacerlo mejor que esto.

Upstream dm comenta sobre este tema:
http://device-mapper.org/blog/2013/12/17/thin-provisioning-and-discard-support/

Tener este problema en CentOS (2.6.32-358.23.2.el6.x86_64) con Docker 0.7.0, también. Viejo, pero el problema no se limita a Ubuntu.

El mismo problema en Arch GNU / Linux 3.12.6-1-ARCH, Docker versión 0.7.2.

Todavía existe en 0.7.0 en CentOS.

Todavía existe en 0.7.2 en ubuntu 12.04.3 LTS.

Gran parte del espacio está en docker/devicemapper/devicemapper/data y metadata , pero también en docker/devicemapper/mnt

Es genial que aprendí que puede ver los sistemas de archivos de contenedor en docker/devicemapper/mnt/SOME_KIND_OF_ID/rootfs

pero no es nada agradable que mi disco duro esté casi completamente consumido y solo se pueda arreglar con rmdir -r docker .

Estoy teniendo un problema similar al escribir soporte de Docker para rspec-system. Mi máquina virtual de prueba (host de la ventana acoplable) tiene una unidad de 8 GB y después de crear imágenes repetidamente sin eliminarlas, mi unidad se llena. Pero después de eliminar todas las imágenes y contenedores, la unidad todavía está 100% llena. Pensé que era un error ID-10T, pero me di por vencido y destruí la máquina virtual por completo.

Todavía existe en 0.7.5 en ubuntu 13.04.

Este problema ha sido solucionado por PR # 3256, que se fusionó recientemente. Esta corrección se incluirá en una versión futura.

Estoy cerrando este problema ahora porque la solución se ha fusionado con master.

Nota: No se ha solucionado _completamente_ hasta que también ejecute un kernel con http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= 6d03f6ac888f2cfc9c840db0b965436d32f1816d en él. Sin eso, la corrección de Docker es solo parcial.

¿Cuál es la solución para eliminar el espacio? Estoy usando rhel 6.5 y puede que tarde un poco en obtener el nuevo kernel.

Enviado desde mi iPhone

El 21 de enero de 2014, a las 6:18 a. M., Alexander Larsson [email protected] escribió:

Nota: No está completamente arreglado hasta que también ejecute un kernel con http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= 6d03f6ac888f2cfc9c840db0b965436d32f1816d en él. Sin eso, la corrección de Docker es solo parcial.

-
Responda a este correo electrónico directamente o véalo en GitHub.

@logicminds No existe una manera fácil de recuperar el espacio en el

@alexlarsson ¿Esto también afecta a OEL 6.5? El OEL 6.5 en realidad usa el kernel de Linux uek 3.8 y, dado que tengo la opción entre cambiar del kernel 2.6 al 3.8, esto podría ser un cambio simple para mí.

@logicminds Ni siquiera sé si esa confirmación está en el kernel ascendente todavía. Ese enlace es del árbol del mapeador de dispositivos. Definitivamente no está en 3.8.

Estoy pensando en crear una herramienta como fstrim que pueda usarse para recuperar el espacio.

El problema de https://bugzilla.redhat.com/show_bug.cgi?id=1043527 ha sido cerrado, oficialmente debido a "datos insuficientes". ¿Significa eso que el parche no llegará al kernel? ¿Sigue siendo necesario?

@vrvolle El parche que soluciona el problema que utiliza Docker ya está en sentido ascendente. Sin embargo, no parece haber ningún trabajo previo que haga que esa solución sea innecesaria.

Todavía tengo este problema con la ventana acoplable 0.9 en centos 6.5 con el kernel predeterminado 2.6.32.

No estoy seguro de entender lo que dijo anteriormente sobre esta confirmación en el mapeador de dispositivos. ¿Podría confirmar que si migro mi kernel a 3.8 este error debería resolverse?

Gracias por adelantado.

@ nicolas-van No, necesitas este compromiso: https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316

Está en 3.14, y puede estar en varios backports 3.xy

Instalé hace algún tiempo la ventana acoplable para crear una imagen y ejecutarla dentro de un contenedor. Luego, algún tiempo después, borré todas las imágenes y contenedores, incluida la aplicación Docker y la carpeta principal.
Ahora me doy cuenta de que de un total de 4GB / 24GB libres / usados ​​(df -h), el comando du / -sh informa solo 10GB, por lo que otros 10Gb no se contabilizan. Eso es menos el tamaño de las imágenes temporales generadas con Docker, ¿podría estar relacionado con este error? He usado centos 6.5 y docker 0.9.

Eliminé la ventana acoplable con yum y los desarrolladores de / dev / mapper / docker * con dmsetup, y también rm / var / lib / docker -Rf, y aún así, los informes del disco con df 10gb se usan que no puedo encontrar en ningún lado.

@Jacq Es posible que algún archivo aún se mantenga vivo mediante un proceso que tiene un descriptor de archivo abierto. ¿Reiniciaste? Eso aseguraría que eso no suceda.

Ejecuto Linux 3.14.4-1-ARCH y Docker 0.11.1, eliminé todas las imágenes y contenedores.
y el archivo / var / lib / docker / devicemapper / devicemapper simplemente se quedó, consumiendo alrededor de 1.5GB

aquí está la salida de después de que estuve jugando con algunas cosas de mongodb, supongo que el tamaño del archivo debe asignarse escasamente porque mi / var ni siquiera es tan 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

Disculpe, ¿el error ya está arreglado? Lo encontré en gentoo.

@bolasblack Ejecuté gentoo y encontré este problema. ¿Descubriste algo?

Estoy usando las últimas fuentes de gentoo que son 3.14.14 para x86_64. Miré https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316?diff y ese parche se aplica a mis fuentes. Tengo Docker Docker versión 1.1.0, compilación 79812e3.

@alexlarsson Gracias por devolver su atención a este problema cerrado después de tanto tiempo. Parece que todavía está causando problemas. ¿Alguna noticia sobre el estado del # 4202?

¡Esto sigue siendo un problema! Creo que voy a volver a usar AUFS por el momento.

@daniellockard AUFS parece estar desaprobado extraoficialmente: # 783 y # 4704, así que buena suerte con eso.

Vaya ... ¿A dónde se fueron esos 25GB? Oh, en ese único archivo ... Estoy ejecutando el kernel 3.16.2 f20 64b

El enlace a la 'solución alternativa' está roto ... ¿qué es? y mi kernel lo soporta ... si Torvalds cometió en 3.14, sospecho que Fedora debería verlo en 3.16, ¿no?

+1

+1

+1

+1 todavía parece estar sucediendo en Ubuntu Trusty, 3.13.0-36-generic con Docker versión 1.3.1, compilación 4e9bbfa

+1 también en Trusty. ¿Vale la pena comprobar en 14.10 que usa 3.16?

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

Etiquetar a los principales confirmadores porque esto es ridículo. Es necesario que haya una conversación pública sobre esto y una admisión por parte del equipo de Docker de que este error puede llevar a contenedores o sistemas que se rompen periódicamente y necesitan ser recreados. Ya conozco a varias personas que han tenido que implementar soluciones locas de DevOps, como cambiar periódicamente la imagen de sus hosts Docker cada semana o dos porque sus bots de compilación tienen mucha rotación. Presenté este problema hace casi un año y, por lo que puedo decir, no se ha creado una solución definitiva, y los kernels más antiguos que aparentemente son compatibles no lo son.

Equipo de Docker: investigue para determinar qué versiones del kernel se ven afectadas, por qué y qué parche solucionará el problema, y ​​documentarlo. Publique esa información junto con las versiones de kernel que admite, porque en este momento los consumidores de Docker están recibiendo este problema una y otra vez, como lo demuestra el hecho de que todavía recibo correos electrónicos sobre este tema cada semana o dos. En serio, este es un problema importante y ha sido un problema desde antes de la versión 1.0.

Como lo veo, hay varias opciones posibles para solucionar este problema de una manera satisfactoria que detendrían los correos electrónicos que sigo recibiendo por +1 sobre este problema:

1. Notifique a los usuarios cuando Device-Mapper se esté utilizando en un kernel no compatible y bríndeles instrucciones detalladas sobre cómo recuperar espacio y, si es posible, configure automáticamente un proceso para hacer esto en Docker. Aconsejaría que este aviso también debería emitirse cuando se usa la CLI de la ventana acoplable contra un host que sufre este problema, de modo que cuando se administran de forma remota los hosts desde la CLI de la ventana acoplable, los usuarios se dan cuenta de que algunos hosts pueden no recuperar espacio correctamente.
2. Solucione el problema (de alguna manera). No sé lo suficiente sobre el desarrollo del kernel para saber qué implicaría esto, pero, según mi lectura de principiante, sugiero esto:

a. Como el mapeador de dispositivos es un módulo del kernel, lleve una versión funcional y funcional del mismo al árbol de fuentes de Docker como dm-docker

segundo. Realice suficientes cambios en dm-docker que pueda coexistir con el mapeador de dispositivos.

C. En las plataformas afectadas, instale el módulo del kernel dm-docker en la instalación y utilice de forma predeterminada dm-docker .

1. Modifique sus documentos de instalación y el sitio docker.com para incluir una advertencia sobre las versiones del kernel afectadas y agregue una verificación de tiempo de ejecución a los paquetes para verificar el funcionamiento correcto del mapeador de dispositivos y, si no, infórmelo al usuario.

Este debería ser un problema de bloqueo para la próxima versión estable de Docker, porque es simplemente inaceptable seguir adelante y dejar a los usuarios en la estacada.

Personalmente, veo CoreOS como la única distribución de Linux estable para Docker (hasta que se resuelva este problema).

Equipo de Docker: Sé que este problema no es causado por su componente, pero por favor, ayúdenos a usar su software también en otras distribuciones de Linux. Estaría bien si también puede mencionar este problema como una limitación bien conocida de Docker en la documentación, para que otras personas no pierdan el tiempo.

¡Gracias!
Martín

+1 hay que hacer algo.

Sería bueno si hubiera algo más evidente para este problema que tener que profundizar en la lista (cerrada) de problemas de github. Tomó mucho tiempo descubrir que este era el problema subyacente y hubiera sido bueno tener visibilidad de este problema.

Nosotros, los desarrolladores de mapeadores de dispositivos ascendentes (Joe Thornber y yo) teníamos una conciencia absolutamente _ cero_ de que este problema sigue siendo un problema para la gente. Solucionamos el problema inmediatamente una vez que nos @alexlarsson en diciembre de 2013) y lo etiquetamos para incluirlo en _todos_ los kernels estables en ese momento, consulte: http://git.kernel.org/linus/19fa1a6756ed9e9 ( "dm thin: arregla el soporte de descarte en un bloque previamente compartido")

Joe Thornber se dio cuenta de que @alexlarsson implementó trim-pool en el código de
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

Entonces ... dicho todo, los usuarios que están ejecutando kernels que no tienen el commit upstream 19fa1a6756ed9e9 ("dm thin: arregla el soporte de descarte en un bloque previamente compartido") necesitan arreglarlo ejecutando kernels que tengan mejor soporte. Sin embargo, puedo enviar fácilmente una nota a rellenar la solución a cualquier kernel estable que no la tenga. Por favor, avíseme cuál (s) kernel (s) estable (s) no tiene esta solución.

En el futuro, querremos que Docker ejecute periódicamente 'thin_trim' contra el dispositivo de grupo delgado que está usando Docker. Pero cruzaremos ese puente una vez que 'thin_trim' esté ampliamente disponible en las distribuciones.

@shabbychef @daniellockard no, los AUF no están desaprobados; primero, solo uno de esos problemas está cerrado, y leyendo, supongo que https://github.com/docker/docker/issues/783#issuecomment -38731137 es vale la pena leer:

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 ¿ podrías agregar algo a hack/check_config.sh para decirles a los usuarios que su kernel no tiene este parche?

@SvenDowideit, lamentablemente, el cambio en cuestión no se identifica en un kernel arbitrario. Para empezar, la confirmación 19fa1a6756ed9e9 no superó la versión de los objetivos delgados o del grupo delgado. Pero incluso si lo hiciera, esa versión variará en todos los núcleos estables (y por eso los cambios de versión dentro de una confirmación 'estable' son malos ... ya que es motivo de edición manual de todos los núcleos a los que se retrocede la confirmación).

PERO, los usuarios que tienen una versión de destino delgada y de grupo delgado> = 1.12.0 tendrán la solución. Entonces granos> = 3.15. La ventana acoplable que están ejecutando los usuarios también debería incluir la confirmación de docker.git 0434a2ce de @alexlarsson ("devmapper: agregar la opción blkdiscard y deshabilitarla en dispositivos sin formato")

Para su información, al ejecutar 'dmsetup targets' se enumerarán las versiones de destino thin y thin-pool (siempre que el módulo del kernel dm-thin-pool esté cargado).

Gracias por prestar atención a esto. Se lo mencionamos a los tipos del stand en Re: Invent la semana pasada.

@snitm por lo que la dmsetup targets debe agregarse a la salida check-config ?

@snitm

¿Sería posible crear una prueba automatizada que creara un dispositivo mapeador de dispositivos de aprovisionamiento fino, realizara algunas operaciones en él que no pudieran recuperar espacio libre en un kernel sin parche e informara un código de estado basado en eso?

@SvenDowideit, ¿espera detectar nuevos núcleos infractores antes de que comiencen a hacer uso del aprovisionamiento ligero de DM en la parte superior del bucle invertido?

@AaronFriel parece extremadamente limitado en su alcance para estar tan obsesionado con esta solución en particular. Hay más en la implementación de nivel empresarial del aprovisionamiento ligero de DM que asegurarse de que esta solución esté en su lugar (realidad desafortunada). El objetivo de aprovisionamiento fino de DM ha experimentado numerosas mejoras en el manejo de errores, el rendimiento y las funciones desde que el compromiso 19fa1a675 fue actualizado. Todo lo cual es importante al implementar el aprovisionamiento ligero DM en producción.

Así que, dando un paso atrás, puedo disfrutar trabajando para una empresa que entiende que los productos en capas deben desarrollarse en conjunto con todas las capas subyacentes. Y tengo poco interés en admitir el aprovisionamiento ligero DM para N kernels arbitrarios emparejados con Docker.

Y resulta que creo firmemente que nadie debería utilizar el aprovisionamiento fino DM con dispositivos de bucle de retorno como dispositivos de respaldo. Ese fue un truco completo que se fusionó con la ventana acoplable sin la restricción adecuada o sin preocuparse por "¿cómo se ve esto en producción?".

Me he dado cuenta de que una implementación adecuada de la ventana acoplable en el aprovisionamiento ligero DM requiere las funciones de administración orientadas a la empresa que proporciona la configuración del aprovisionamiento ligero basada en lvm2. Entonces, con eso en mente, he trabajado constantemente para hacer que una nueva solución de administración híbrida funcione, consulte este PR:
https://github.com/docker/docker/pull/9006

Este trabajo depende de:
1) lvm2> = 2.02.112
2) DM thin-pool target versión> = v1.14.0 (también conocido como cambios realizados en linux-next para la inclusión de Linux 3.19)

RHEL7.1 tendrá estos cambios. Y RHELAH (Atomic Host) también lo hará. Cualquier otra distribución / producto que desee implementar correctamente la ventana acoplable en el aprovisionamiento fino de DM también debería hacerlo.

@snitm sí, estoy tratando de reducir la cantidad de usuarios que se ven afectados por una misteriosa rotura, lo que luego lleva aún más tiempo para que alguien se dé cuenta de que podría ser este dolor oscuro, y luego tratar de pedirle al usuario que lo averigüe que la falta de algún parche misterioso es el problema.

y así, en el contexto de su información restante, quiero reducir la cantidad de núcleos que causarán esta horrible sorpresa :)

@SvenDowideit OK, proporcioné la información que Docker (o sus usuarios) podrían usar para verificar DM thinp sobre la compatibilidad de loopback en este comentario: https://github.com/docker/docker/issues/3182#issuecomment -63706507

@snitm , @AaronFriel
Me encuentro con lo que parece ser este problema en AWS beanstalk, Amazon AMI.
(Quedándose sin espacio)
Linux ip-172-31-63-145 3.14.23-22.44.amzn1.x86_64 # 1 SMP Mar 11 de noviembre 23:07:48 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux

$ sudo versión docker
Versión del cliente: 1.3.2
Versión de la API del cliente: 1.15
Go versión (cliente): go1.3.3
Confirmación de Git (cliente): c78088f / 1.3.2
OS / Arch (cliente): linux / amd64
Versión del servidor: 1.3.2
Versión de la API del servidor: 1.15
Go versión (servidor): go1.3.3
Confirmación de Git (servidor): c78088f / 1.3.2

Sigo recibiendo este error con Ubuntu 14.04 y Docker 1.4.1.

No cuente con que las versiones thin-pool y thin sean> = 1.12.0 para significar que está bien.Estamos ejecutando máquinas virtuales CentOS 6.5 con el kernel 2.6.32-431.29.2.el6.x86_64 y los objetivos dmsetup informan que thin-pool y thin son ambos v1.12.0. Sin embargo, estoy atascado con un archivo de datos de 40 GB que no se está liberando.

¿Cuáles son las implicaciones de ejecutar esto en CentOS / RHEL 6.5 con este error? ¿Estás de acuerdo con> = 100G de espacio libre? ¿Asumo que esto eventualmente llena cualquier tamaño de disco? ¿O está limitado a 100G?

Tenga en cuenta que 6.5 no tiene el kernel más nuevo disponible para centos. Recomendaría una simple 'actualización de yum' a 6.6 y un reinicio para probar con el kernel 2.6.32-504.3.3.

Confirme que las últimas actualizaciones de kernel y distribución para CentOS 6 funcionan bien y liberan espacio.

ripienaar: ¿Puede indicar explícitamente qué CentOS 6 y versión de kernel está utilizando? Solo quiero asegurarme de que cuando pase la información, tenga toda la información que necesito.

Gracias.

Como @reiz comentó anteriormente, esto está sucediendo con la última ventana acoplable de Ubuntu 14.04 +. Los destinos de dmsetup muestran thin / thin-pool de v1.9.0 en una de nuestras instancias (no hay contenedores de Docker activos). Los destinos de dmsetup no muestran ninguna entrada delgada en una instancia similar con contenedores de Docker activos. (Realmente no estoy pidiendo ayuda con esto, solo agrego datos (con suerte útiles)).

Cosas básicas del sistema operativo:

# 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 acceder a ese kernel, no recuperaba espacio.

@jperrin menciona que esto se resolverá usando centos kernel 2.6.32-504.3.3. ¿Se sabe qué confirmación del kernel (conjunto de confirmaciones) que resuelve este problema?

Actualmente estoy usando uno de Oracle Enterprise Linux 3.8 UEK.

¿Existe alguna solución para esta situación? en AWS es fácil simplemente volver a crear la instancia, pero en el entorno de desarrollo local no es bueno notar que la partición / var pertenece en un 90% al mapeador de dispositivos debido a la ventana acoplable; pronto no tendrá espacio ni siquiera para registros o diarios

@donrudo como arriba - actualice a la última versión de centos 6 - el kernel 504.3.3.

Eso está bien para centos, pero algunos de nuestros desarrolladores están usando Fedora y otros OpenSuse.

Todos los cambios de aprovisionamiento ligero de DM se envían primero en sentido ascendente. Entonces, si Centos 6 es fijo, también lo es en sentido ascendente. Las diversas distribuciones necesitan eliminar arreglos o reajustar de forma más agresiva.

@ripienaar Te preguntaré de nuevo, ¿sabes qué confirmación del kernel (o conjunto de confirmaciones) son necesarias para la corrección?

@lexinator nope

Veo este problema en Ubuntu 14.04 Trusty y kernel 3.13.0-36-generic. Una posible solución es adjuntar el almacenamiento de AWS EBS al directorio para que pueda escalar de forma indefinida.

Chicos, este problema duele mucho. CoreOS se está moviendo a ext4 ahora y pronto también tendremos todos estos problemas en CoreOS.

¿Cómo pueden las personas usar Docker (en dev o prod) mientras este problema no se soluciona durante más de un año? ¿Todo el mundo tiene discos infinitos?

Creo que se están moviendo a ext4 para superposición, no para devmapper. Pero eso es
solo la palabra en la calle ...

El miércoles 28 de enero de 2015, Sergey [email protected] escribió:

Chicos, este problema duele mucho. CoreOS se está moviendo a ext4 ahora y pronto
también tendrá todos estos problemas en CoreOS.

Cómo las personas pueden usar Docker (en dev o prod) mientras este problema no está resuelto para
mas de un año? ¿Todo el mundo tiene discos infinitos?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/3182#issuecomment -71800923.

Estoy confundido. Mi espacio en disco en una instancia de Google es solo 10G, pero el tamaño de / var / lib / docker / devicemapper / devicemapper / data se muestra como 100G. No puedo recuperar espacio incluso después de eliminar todos los contenedores e imágenes.

Es un archivo escaso. Use ls -sh lugar de ls -l , o alternativamente, du -h

Puedo informar esto en Ubuntu 13.04 (probablemente no sea sorprendente).

¿Es la única solución real a esto en este momento proporcionar suficiente espacio en disco para anticipar el crecimiento de devicemapper?

Todo este hilo es bastante ridículo. Un usuario de Debian tras otro quejándose. Si está viendo un problema, debe cambiar a una distribución que tenga el mantenimiento adecuado o trabajar con los mantenedores de la distribución para que solucionen el problema. Estas distribuciones no se mantienen al día con las correcciones o mejoras. Ignoraré todas las peticiones futuras para que alguien solucione este problema en distro $ foo, dado que la solución ya está claramente en sentido ascendente (consulte CentOS o RHEL). Abra un error contra la distribución rota en cuestión y haga referencia a este problema.

No es tan ridículo cuando Docker sostiene que tienen soporte en las siguientes 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)

¿Cómo puede tener una llamada de soporte general para 14.04 cuando este problema es obviamente tan frecuente? Obviamente, Docker debería eliminar el soporte general para ciertos núcleos en ciertas distribuciones.

Estoy usando CentOS y la actualización del kernel parece haber mejorado el problema de uso del mapeador de dispositivos de ejecución.

Independientemente, gracias por tu trabajo @snitm.

Para aquellos que tienen este problema en Ubuntu, asegúrese de que está limpiando adecuadamente las imágenes / contenedores antiguos de Docker. Descubrí que mi secuencia de comandos de limpieza no se estaba ejecutando cuando pensé que lo estaba, y por eso estaba usando tanto espacio.

`` `#! / bin / bash

Eliminar todos los contenedores

docker rm $ (docker ps -a -q)

Eliminar todas las imágenes

docker rmi $ (imágenes de docker -q)
''

@TylerMills tenga en cuenta que docker rm _no_ eliminará los volúmenes creados por los contenedores. Si sus contenedores utilizan volúmenes, debe usar docker rm -v para que la ventana acoplable también elimine los volúmenes.

@snitm Esto afectado (usando Ubuntu 14.04). Si bien puede que no sea culpa de Docker específicamente, deberían tener un gran interés en solucionarlo, ya que se refleja mal en toda la experiencia.

También tenga en cuenta que me encontré con este problema y esto es lo que hice para solucionarlo:

Sin embargo, en mi caso, debido a que el dispositivo / var está montado para alcanzar el 100% de uso, la única forma de evitar que el host entre en pánico en el kernel es matar el proceso de la ventana acoplable directamente (es decir, emitir cualquier comando de la ventana acoplable entraría en pánico).

Luego, elimine manualmente cualquier proceso usando los montajes de devicemapper usando este comando:

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

luego pude desmontar cualquier montaje de devicemapper usando:

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

esos pasos liberaron todos los descriptores de archivos que me permitieron recuperar el espacio / eliminar archivos lo que sea ...

En ese momento, en mi caso, tenía más sentido mover el directorio / var / lib / docker a un montaje con más espacio y configurar el demonio docker para usar un directorio de inicio diferente usando el argumento -g

gracias a Alexander Larsson a través de Adam Miller

Siguiendo con el comentario de @dekz , probablemente sería una buena idea si la guía de instalación no https://docs.docker.com/installation/ubuntulinux/

Gracias @JohnMorales. Una pequeña advertencia sobre esto de Docker sería una gran idea.

+1

+1

Recientemente nos ha molestado este sistema operativo Ubuntu 14.04.2 LTS (3.16.0-30-generic) y todavía estamos luchando por encontrar una solución. Parece que cambiar a CentOS 6.6 (que supuestamente tiene la corrección del kernel) o montar un volumen que tiene un disco más grande son las únicas soluciones.

¿Alguien que ejecuta Ubuntu ha encontrado una solución aceptable?

Estoy de acuerdo, Docker debería hacerse cargo y abordar este problema; es un error grave que necesita documentación y mensajes de advertencia, por lo que más personas no caen ingenuamente en la misma trampa.

Estoy de acuerdo con @natea
Estoy enfrentando el mismo problema con redhat 6.5 y está poniendo un gran signo de interrogación si Docker está listo para producción y estamos comenzando a buscar alternativas.
No me importa siquiera obtener una solución manual para resolver el problema, pero en este momento, no conozco ninguna factible.

@sagiegurarie tenga en cuenta que aumentamos los requisitos para CentOS a 6.6 debido a varios problemas con 6.5 (y el kernel asociado). Es probable que este requisito aún no esté en el sitio web de documentos en vivo, pero estará en la próxima versión, tal vez antes.

¿Entonces la respuesta del problema # 11643 no es relevante? eso significa que no podemos usar Redhat 6.5?

@natea @sagiegurari Lo que nos funciona es el "arreglo" manual sugerido por @TylerMills

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

La desventaja, por supuesto, es que luego debe volver a extraer todas las imágenes y ejecutar los contenedores nuevamente.

@bkeroackdsc Recuerdo que también borré todos los contenedores e imágenes antes y eso no lo resolvió, pero lo intentaré de nuevo.

¡Hola! Me gustaría saber si este problema todavía existe en ubuntu-15.04. Que está ahora en el kernel linux-3.19. Muchas gracias.

Si está en ubuntu-15.05 con ese kernel, ¿por qué no usa superposición?
mejor que devicemapper

El jueves 7 de mayo de 2015 a las 11:26 a. M., Dreamcat4 [email protected] escribió:

¡Hola! Me gustaría saber si este problema todavía existe en ubuntu-15.04.
Que está ahora en el kernel linux-3.19. Muchas gracias.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99968299.

@jfrazelle Oh, cierto. ¿Cómo es? ¿Usas superposición? He estado asumiendo (hasta ahora) que el soporte de superposición todavía era experimental a partir del kernel 3.19.

Sí, uso superposición :) Esperamos moverlo hacia arriba en la lista en 1.7 Lost of Us
úsalo y ámalo

El jueves 7 de mayo de 2015, Dreamcat4 [email protected] escribió:

@jfrazelle https://github.com/jfrazelle Oh, claro. ¿Cómo es? Hacer
usas superposición? He estado asumiendo (hasta ahora) que
El soporte de superposición todavía era experimental a partir del kernel 3.19.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99982543.

@sagiegurari ¿

@jperrin porque no es mi decisión :)
De todos modos, estoy tratando de verificar con todos los equipos para ver si Redhat 7 estaría bien para la producción.

Esto parece seguir siendo un problema en CentOS7 (3.10.0-123.el7.x86_64). Configuré una nueva caja de CentOS e instalé Docker v1.6.0. El archivo de datos de devicemapper nunca disminuye de tamaño después de un rmi sudo docker. Estoy buscando obtener una caja CentOS6.6 para probarlo.

v1.6.0 en Ubuntu 14.04 parece tener un efecto positivo (sobre v1.5.0)

también parece funcionar bien en centos 7, que supongo que también puede decirse para redhat 7
pero redhat 6.5 no lo es, y sugiero que se indique en los documentos.

Esto debería funcionar en la última ventana acoplable ascendente. Y el último comentario de @sagiegurari parece implicar eso. (funciona en centos 7).

Si ese es el caso, deberíamos cerrar este error.

Entonces, ¿sigue ocurriendo este problema con la última ventana acoplable? Si no, vamos a cerrarlo.

bueno ... ejecutar más pruebas parece proporcionar resultados inciertos.
digamos que es mucho mejor, pero es posible que aún tenga fugas, solo que mucho más lento.
Haré más comprobaciones para confirmar.

@sagiegurari

¿Puede darme más detalles sobre cuál es el problema al que se enfrenta y también sobre su entorno? El título del problema dice que el espacio no se recupera tras la eliminación de la imagen / contenedor, y la última ventana acoplable ascendente no debería tener tales problemas.

¿Puede tomar la ventana acoplable ascendente, construir un binario dinámico, crear un nuevo grupo delgado (en un directorio nuevo / var / lib / docker /), extraer una imagen, eliminarla y ver la información de la ventana acoplable y ver si se ha liberado espacio o no.

Con suerte, ejecutaré más pruebas la próxima semana para proporcionar información más exacta.

Admito que lo veo en nuestra máquina de compilación donde creamos y eliminamos muchas imágenes (durante la compilación en sí) + ejecutamos el registro de la ventana acoplable 2.0 (al que siempre enviamos las diferentes imágenes con la etiqueta 'últimas') + ejecutamos algunos contenedores para Realice una prueba inicial de que todo funciona bien (en realidad, no se supone que la prueba se ejecute en esa máquina, pero estamos en la etapa inicial, por lo que creamos / stop / rm muchos contenedores)

Nuestras imágenes son realmente grandes, a veces veo un tamaño virtual de más de 2 GB, por lo que si hay un problema, se muestra más rápido que con las imágenes habituales que normalmente rondan los 400 mg.

de todos modos, intentaré ejecutar algunas pruebas para ver el comportamiento y proporcionar más detalles la próxima semana.

Con la versión 1.6.0 de Docker, compile 4749651 / 1.6.0 en el kernel de Linux 3.14.35-28.38.amzn1.x86_64

La eliminación de imágenes reduce el espacio en disco reclamado por la ventana acoplable.

@vbatts

¿Podemos cerrar este problema? No creo que en la última ventana acoplable tengamos el problema de recuperar el espacio de la imagen / contenedor de los archivos oop. Si surge algo específico, se puede abrir una nueva edición con detalles específicos.

@rhvgoyal No veo una razón para apresurarme y cerrar este problema después de que tanta gente se queje de tantas plataformas / versiones.

@sagiegurari

No sé qué ganamos manteniendo el tema abierto. Sé que está arreglado aguas arriba. Hay tantos problemas abiertos. La gente los usa como tablero para anotar las observaciones.

Siento que mantener un tema abierto tiene sentido solo si hay un problema reproducible real. De lo contrario, esta lista de problemas sigue creciendo y es difícil saber en cuál centrarse.

Nadie le impide agregar más datos a este problema una vez que lo tenga.

@rhvgoyal ¿a qué etiqueta te refieres con el último upstream?

@rhvgoyal Di el último compromiso. Simplemente clono el último árbol de git y lo pruebo. ¿Realmente importa?

Se informan muchos problemas en versiones de Docker antiguas y kernels antiguos. Creo que el primer paso debería ser ver si el mismo problema es visible en la última ventana acoplable y en el kernerl relativamente más nuevo. Eso nos da una idea de si sigue siendo un problema o algo que no se ha solucionado en versiones anteriores.

Cuando alguien regrese y lo lea en el futuro, sí. Quería saber en qué versión estaba arreglado.

Emitimos descartes en el caso de dispositivos loopback. En realidad, se hizo hace mucho tiempo. Creo que 1.6 debería tenerlo.

@stanislavb probó con 1.6 y funcionó para él.

Si se refiere a mi primer comentario en este número, verá que también probé con v1.6.0 en centos7 y todavía tenía el problema.

@alexDrinkwater

Ok, ¿puedes reproducirlo? ¿Qué tipo de piscina delgada usaste (sobre los dispositivos de bucle?). ¿Reinició Docker o sucede la primera vez que inicia Docker?

En algunos casos, puede suceder que la ventana acoplable esté usando dispositivos de bucle y luego la ventana acoplable se reinicie, puede suceder que el grupo no se haya apagado porque algún dispositivo estaba ocupado en algún lugar. Al reiniciar la ventana acoplable
encuentra el grupo que ya está allí y no tiene conocimiento de que se estén utilizando dispositivos de bucle invertido y no emite descarte. Me pregunto si se encontró con esa situación.

CentOS 7

Docker versión 1.6.2.el7, compilación c3ca5bb / 1.6.2

Antes de la limpieza de imágenes

[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% /

Después de un poco de 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, acabo de arrancar una imagen centos7 y probé Docker 1.6 y no veo el problema. Estos son los pasos.

[ root @ centos7-generic ~] # versión de Docker
Versión del cliente: 1.6.0
Versión de la API del cliente: 1.18
Go versión (cliente): go1.4.2
Confirmación de Git (cliente): 8aae715 / 1.6.0
OS / Arch (cliente): linux / amd64
Versión del servidor: 1.6.0
Versión de la API del servidor: 1.18
Go versión (servidor): go1.4.2
Confirmación de Git (servidor): 8aae715 / 1.6.0
OS / Arch (servidor): linux / amd64

Ya hay una imagen importada.

[ root @ centos7-generic ~] # imágenes de docker
ETIQUETA DE REPOSITORIO ID DE IMAGEN CREADA TAMAÑO VIRTUAL
docker.io/fedora última ded7cd95e059 Hace 2 semanas 186.5 MB

Aquí está el resultado de la información de la ventana acoplable.

root @ centos7-generic ~] # información de la
Contenedores: 0
Imágenes: 2
Controlador de almacenamiento: devicemapper
Nombre de la piscina: docker-253: 1-50331788-pool
Tamaño del bloque de la piscina: 65.54 kB
Sistema de archivos de respaldo: xfs
Archivo de datos: / dev / loop0
Archivo de metadatos: / dev / loop1
Espacio de datos utilizado: 525,5 MB
Espacio de datos total: 107,4 GB
Espacio de datos disponible: 20 GB
Espacio de metadatos utilizado: 892,9 kB
Espacio total de metadatos: 2.147 GB
Espacio de metadatos disponible: 2.147 GB
Sincronización Udev compatible: verdadero
Archivo de bucle de datos: / var / lib / docker / devicemapper / devicemapper / data
Archivo de bucle de metadatos: / var / lib / docker / devicemapper / devicemapper / metadata
Versión de la biblioteca: 1.02.93-RHEL7 (28/01/2015)
Controlador de ejecución: native-0.2
Versión de Kernel: 3.10.0-229.el7.x86_64
Sistema operativo: CentOS Linux 7 (Core)
CPU: 2

[ root @ centos7-generic ~] # docker rmi fedora
Untagged: fedora: último
Eliminado: ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4
Eliminado: 48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731

[ root @ centos7-generic ~] # información de la
Contenedores: 0
Imágenes: 0
Controlador de almacenamiento: devicemapper
Nombre de la piscina: docker-253: 1-50331788-pool
Tamaño del bloque de la piscina: 65.54 kB
Sistema de archivos de respaldo: xfs
Archivo de datos: / dev / loop0
Archivo de metadatos: / dev / loop1
Espacio de datos utilizado: 307,2 MB
Espacio de datos total: 107,4 GB
Espacio de datos disponible: 20,22 GB
Espacio de metadatos utilizado: 733,2 kB
Espacio total de metadatos: 2.147 GB
Espacio de metadatos disponible: 2.147 GB
Sincronización Udev compatible: verdadero
Archivo de bucle de datos: / var / lib / docker / devicemapper / devicemapper / data
Archivo de bucle de metadatos: / var / lib / docker / devicemapper / devicemapper / metadata
Versión de la biblioteca: 1.02.93-RHEL7 (28/01/2015)
Controlador de ejecución: native-0.2
Versión de Kernel: 3.10.0-229.el7.x86_64
Sistema operativo: CentOS Linux 7 (Core)
CPU: 2

Aviso El uso de datos se redujo de 525 MB a 307 MB. Así que borrar una imagen me devolvió el espacio.

Ok, olvidé pegar el tamaño del archivo de bucle antes y después de la operación. aquí está.

• Antes de tirar de la imagen.
  $ cd / var / lib / docker / devicemapper / devicemapper
  $ du -h datos
  293M de datos
• Después de la extracción de la imagen
  [ root @ centos7-generic devicemapper] # du -h datos
  499M de datos
• Después de la eliminación de la imagen
  [ root @ centos7-generic devicemapper] # du -h datos
  293M de datos

Entonces, mi archivo de bucle en realidad se redujo después de la eliminación de la imagen. Creo que eso es de lo que te quejas.

@stanislavb

¿Estás usando archivos de bucle? No son visibles en la información de su ventana acoplable. Creo que se está encontrando con el mismo problema en el que, cuando se inició la ventana acoplable, el grupo ya estaba allí.

¿Puede verificar el tamaño de los archivos de respaldo de bucle (/ var / lib / docker / devicemapper / devicemapper / data) y asegurarse de que el archivo se encoja después de la eliminación de la imagen? (du -h).

@rhvgoyal
CentOS 7, Docker versión 1.6.2.el7, compilación 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, entonces el tamaño del dispositivo de bucle está disminuyendo.

También verifiqué desde el código. Emitiremos el descarte incluso si al reiniciar la ventana acoplable se encuentra un grupo delgado que ya está allí.

    // 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
    }

Según el código anterior, los descartes se deshabilitan solo si el usuario pasa un dispositivo de bloque de datos o un grupo delgado. Dado que tampoco pasamos, los descartes continúan. Por eso te está funcionando.

@alexDrinkwater Ahora tenemos dos puntos de datos que están fijos en 1.6. ¿Todavía tiene preocupaciones para cerrar este problema?

CentOS 6.6

Docker versión 1.5.0, compilación a8a31ef / 1.5.0

Antes de la limpieza de imágenes

[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% /

Tamaño comprobado del archivo de datos con 1929 imágenes restantes

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

Después de un poco de 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, incluso en 1.5 funciona.

Probé esto en una máquina nueva.

Docker versión 1.6.0, compilación 8aae715 / 1.6.0

Antes de tirar:

/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

después de tirar:

/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

quita la imagen:

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

después de eliminar:

/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

Avíseme si tiene más detalles de mi máquina o versiones, etc.

@alexDrinkwater

Parece que está montando un dispositivo separado en / var. ¿Cuál es el sistema de archivos en ese dispositivo y cuáles son las opciones de montaje?

También puedes darme lo siguiente.

• tabla dmsetup
• estado de dmsetup
• cat / etc / sysconfig / docker-storage

¿Puede probar el caso más simple de mantener / var en la raíz con el sistema de archivos xfs? Intentando reducir un poco el problema.

@alexDrinkwater

Monté otro disco con la partición ext4 en / var / lib / docker para que los archivos de respaldo de bucle invertido estén en ext4 (en lugar de xfs) y todavía las cosas funcionan para mí.

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

Realmente no estoy seguro de qué tiene de especial tu configuración.

Ser especifico,

• Antes de tirar
  / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / docker
• Después de la extracción de la imagen
  / dev / vdb1 9.8G 544M 8.7G 6% / var / lib / docker
• Después de borrar la imagen
  / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / docker

@alexDrinkwater

La otra gran diferencia entre su configuración y la mía es la versión del kernel. Estoy usando "3.10.0-229.el7.x86_64" mientras que parece que estás usando "3.10.0-123.el7.x86_64". ¿Puedes actualizar tu kernel y probarlo?

Gracias por la ayuda @rhvgoyal. Hoy no podría actualizar el kernel. Pero aquí están las configuraciones que solicitó:

/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=

No tengo configurada ninguna opción de almacenamiento personalizada.

Lo encontré. Creo que tiene algo que ver con el sistema de archivos ext3. También puedo ver el problema. Pruebe con un sistema de archivos diferente, digamos ext4 o xfs y no enfrentará el problema.

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

• Antes de sacar la imagen
  [ root @ centos7-generic-2 devicemapper] # du -h datos
  293M de datos
• Después de sacar la imagen
  [ root @ centos7-generic-2 devicemapper] # du -h datos
  501M de datos
• Después de la eliminación de la imagen
  [ root @ centos7-generic-2 devicemapper] # du -h datos
  501M de datos

Entonces, por alguna razón, si el archivo loopback está en el sistema de archivos ext3, no funciona. Puede ser que ext3 sea lo suficientemente antiguo como para que los descartes de bucle no funcionen en él.

Gracias, tan pronto como vi que el sistema de archivos era ext3 pensé que podría ser. Supongo que si pudieras reproducir el problema en ext3, podríamos llamar a este problema cerrado. Será una buena referencia para otros.

Como referencia, mis ejemplos de trabajo fueron Docker 1.6.2 en el sistema de archivos xfs y Docker 1.6.0 y 1.5.0 en ext4.

@vbatts

¿Podemos cerrar esto? La recuperación de espacio funciona bien en xfs y ext4. ext3 parece ser demasiado viejo para admitirlo.

@rhvgoyal @vbatts IIRC, hay una verificación de compatibilidad que verifica el sistema de archivos subyacente. ¿Quizás deberíamos agregar un cheque por ext3 si ese es el problema aquí?

editar:
para referencia; daemon / graphdriver / overlay / overlay.go # L115

El controlador de bucle utiliza fallocate () para hacer un agujero en el archivo cuando entra el descarte. La página de manual de Linux de fallocate () verifica que no es compatible con ext3.

/ *
No todos los sistemas de archivos admiten FALLOC_FL_PUNCH_HOLE; si un sistema de archivos no admite la operación, se devuelve un error. La operación es compatible con al menos los siguientes sistemas de archivos:
* XFS (desde Linux 2.6.38)
* ext4 (desde Linux 3.0)
* Btrfs (desde Linux 3.7)
* tmpfs (desde Linux 3.5)
* /

@thaJeztah

Si alguien quiere ejecutar Docker en ext3, supongo que deberíamos permitirlo. Solo que no obtendrán soporte de descarte, por lo tanto, el tamaño del archivo de bucle no se reducirá cuando se eliminen imágenes / contenedores.

@rhvgoyal ¿qué tal mostrar esto en docker info ? Similar a la salida Udev Sync Supported .

@thaJeztah

Ya tenemos una entrada en la información de la ventana acoplable "Sistema de archivos de respaldo". No estoy seguro de por qué dice extfs en lugar de ser preciso sobre ext2 / ext3 / ext4.

Puede haber una advertencia en el momento de inicio en los registros que debe hacer aquí. Algo similar a la advertencia sobre el uso de dispositivos de bucle para piscinas finas.

@thaJeztah

Y creo que deberíamos hacerlo solo si mucha gente se ve afectada por esto. Si no es así, simplemente estamos creando más trabajo y código y puede que no valga la pena.

la estructura syscall.Statfs_t , con el campo Type en ext2, ext3 y ext4 devuelven 0xef53 , y eso es lo que estamos usando para detectar la magia del sistema de archivos.

la estructura syscall.Statfs_t, con el campo Type en ext2, ext3 y ext4, todos devuelven 0xef53, y eso es lo que estamos usando para detectar la magia del sistema de archivos.

Gorrón. Hubiera sido bueno tener esa información para facilitar la identificación de los problemas informados.

Supongo que deberíamos cerrar esto entonces.

cerrando ya que este es un problema con ext3 que está desactualizado. Utilice ext4 o xfs

¿cree que esto podría estar mejor documentado en la documentación principal de Docker de alguna manera?

Ya sea que el problema sea con el sistema de archivos o no, observe cuánta confusión ha generado esto en dos problemas recientes.

Gracias.

volviendo a emitir # 9786

@dbabits sí, creo que mencionar que ext3 tiene algunos problemas podría valer la pena mencionar en los documentos. Aún no tengo idea de cuál sería una ubicación adecuada.

Tiene el mismo problema / similar con XFS.
Estaba en el kernel "3.10.0-123.el7.x86_64", pero se actualizó ahora en "3.10.0-229.el7.x86_64".

Todo se elimina (contenedor, imágenes) pero los datos aún contienen 100 GB.
¿Alguna idea, ayuda?

[ root @ docker0101 ~] # ls -alh / data / docker / devicemapper / devicemapper /
total 80G
drwx ------ 2 root root 32 8 de junio 16:48.
drwx ------ 5 raíz raíz 50 9 de junio 07:16 ..
-rw ------- 1 raíz raíz 100G 16 de julio 21:33 datos
-rw ------- 1 raíz raíz 2.0G 17 de julio 09:20 metadatos

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

[ root @ docker0101 ~] # cat / etc / redhat-release
Versión de CentOS Linux 7.1.1503 (Core)

[ root @ docker0101 ~] # docker ps -a
ID DE CONTENEDOR IMAGEN COMANDO ESTADO CREADO PUERTOS NOMBRES

[ root @ docker0101 ~] # imágenes de la
ETIQUETA DE REPOSITORIO ID DE IMAGEN CREADA TAMAÑO VIRTUAL

[ root @ docker0101 ~] # información de la
Contenedores: 0
Imágenes: 0
Controlador de almacenamiento: devicemapper
Nombre del grupo: docker-253: 0-268599424-pool
Tamaño del bloque de la piscina: 65.54 kB
Sistema de archivos de respaldo: xfs
Archivo de datos: / dev / loop0
Archivo de metadatos: / dev / loop1
Espacio de datos utilizado: 85,61 GB
Espacio de datos total: 107,4 GB
Espacio de datos disponible: 40,91 MB
Espacio de metadatos utilizado: 211,4 MB
Espacio total de metadatos: 2.147 GB
Espacio de metadatos disponible: 40,91 MB
Sincronización Udev compatible: verdadero
Archivo de bucle de datos: / data / docker / devicemapper / devicemapper / data
Archivo de bucle de metadatos: / data / docker / devicemapper / devicemapper / metadata
Versión de la biblioteca: 1.02.93-RHEL7 (28/01/2015)
Controlador de ejecución: native-0.2
Versión de Kernel: 3.10.0-229.7.2.el7.x86_64
Sistema operativo: CentOS Linux 7 (Core)
CPU: 4
Memoria total: 11,58 GiB
Nombre: docker0101

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

[ root @ docker0101 ~] # estado de dmsetup
vg1-lvol0: 0 167772160 lineal
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
Nombre: docker
Versión: 1.6.2
Lanzamiento: 14.el7.centos
Arquitectura: x86_64
Fecha de instalación: vie 17 de julio de 2015 09:19:54 a.m. CEST
Grupo: Sin especificar
Tamaño: 33825026
Licencia: ASL 2.0
Firma: RSA / SHA256, miércoles 24 de junio de 2015 05:43:12 a.m. CEST, clave de identificación 24c6a8a7f4a80eb5
RPM de origen: docker-1.6.2-14.el7.centos.src.rpm
Fecha de construcción: miércoles 24 de junio de 2015 a las 03:52:32 a.m. CEST
Compilar host: worker1.bsys.centos.org

[root @ docker0101 ~] # ls -al / var / lib / docker
lrwxrwxrwx 1 raíz raíz 12 9 de junio 08:21 / var / lib / docker -> / data / docker

[ root @ docker0101 ~] # montaje
/ dev / sda5 en / var tipo xfs (rw, relatime, attr2, inode64, noquota)
/ dev / mapper / vg1-lvol0 en / tipo de datos xfs (rw, relatime, attr2, inode64, noquota)

@tomlux El modo loopback de devicemapper que estás usando está pensado principalmente como una forma de jugar fácilmente con la ventana acoplable. para trabajos serios, el loopback será más lento y tendrá algunas limitaciones. Recomiendo encarecidamente leer http://www.projectatomic.io/docs/docker-storage-recommendation/

Obtendrá un mejor rendimiento y no afectará a cosas como esta, suponiendo que haya aplicado todas las actualizaciones del sistema.

@tomlux

¿Puede agregar "-s" a ls. Eso le dará bloques reales asignados a archivos de datos y metadatos. Ahora mismo muestra el tamaño aparente de los archivos.

Sin embargo, la salida de información de Docker es intrigante. Parece mostrar un uso elevado.

@tomlux

Por tanto, el tamaño real de los archivos de datos y metadatos parece pequeño. Puede utilizar "ls -alsh" para que los tamaños sean más legibles.

Por lo tanto, el tamaño del archivo de datos parece ser de alrededor de 79 MB y el tamaño del archivo de metadatos es de alrededor de 202 KB.

Creo que de alguna manera las estadísticas del grupo delgado sobre la cantidad de bloques utilizados no se ven bien. ¿Un reinicio de la máquina soluciona el problema?

Hice un reinicio después de la actualización del kernel sin éxito.

Ok, entonces los archivos de bucle son grandes y pool cree que tiene muchos bloques usados. Entonces, algo está usando esos bloques. ¿Puede darme salida de.

• docker ps -a
• imágenes de docker
• ls / var / lib / dokcer / devicemapper / metadata / | wc -l
• cierre la ventana acoplable y ejecute lo siguiente.
  thin_dump / var / lib / docker / devicemapper / devicemapper / metadata | grep "dispositivo dev_id" | wc -l

Esto le dirá cuántos dispositivos delgados hay en la piscina.

Mmm
ahora tenemos contenedores MUERTOS pero sin imágenes.
Ya reinicié.

Parece que hay algún problema con el mapeador de dispositivos.
No quiero enviar spam a este problema.
También puedo "rm -f / var / lib / docker" y reconstruir mis contenedores. Todo está escrito.

hacer "estado de dmsetup"

Parece que la piscina está en mal estado y lo más probable es que deba ser reparada.

Hola,

Parecía tener el mismo problema en Ubuntu 14.04. Sin embargo, la causa fueron los volúmenes no deseados (cf. blog http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/). Ejecutando el comando

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

liberó mucho espacio en disco.

Esto no se soluciona de manera significativa. En una instalación de Ubuntu 14.04.x ​​completamente actualizada (la última versión de LTS) y con la última versión de Docker (instalada a través de $ wget -qO- https://get.docker.com/ | sh ), Docker perderá espacio continuamente sin una forma fácil de recuperar. docker stop $(docker ps -q) && docker rm $(docker ps -q -a) && docker rmi $(docker images -q) solo libera una pequeña cantidad de espacio.

La única forma de recuperar todo el espacio es con el siguiente truco:

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

Lo que luego requiere volver a extraer las imágenes que pueda necesitar.

@bkeroackdsc ¿ podría ese espacio también estar relacionado con volúmenes "huérfanos"?

Estoy de acuerdo con @bkeroackdsc, esto no se resuelve.
Le pregunté a @rhvgoyal por qué quería tanto cerrar este caso.
al final, salí de Docker específicamente debido a este problema.
está matando a este producto.

huérfano o no huérfano, no hay una manera fácil y buena de limpiar el espacio.
debe haber una opción de cli de docker para la limpieza, una buena opción de cli de informe de estado y también algún tipo de monitoreo del espacio en disco, ya que este problema le ocurre a demasiadas personas en muchas plataformas.

@bkeroackdsc @sagiegurari

La razón por la que pregunto es que los volúmenes huérfanos no están relacionados con este problema,
no relacionado con devicemapper.

Los volúmenes huérfanos no son
para un contenedor se eliminan automáticamente cuando se elimina el contenedor.
Este _no_ es el caso (y por diseño), porque los volúmenes pueden contener datos
que debería persistir después de eliminar un contenedor.

_Para eliminar un volumen junto con un contenedor_, use docker rm -v [mycontainer] .
Se agregarán funciones de administración de volumen (consulte https://github.com/docker/docker/pull/14242 y https://github.com/docker/docker/issues/8363),
y le permitirá administrar volúmenes "huérfanos".

Un tamaño creciente de /var/lib/docker no tiene por qué ser una indicación
ese mapeador de dispositivos está filtrando datos, porque un aumento en el tamaño de ese directorio
también puede ser el resultado de volúmenes (huérfanos) que no se han limpiado
por el usuario (Docker almacena todos sus datos en esa ruta).

Realmente espero que esos 2 elementos brinden las capacidades necesarias.
Entendí el segundo elemento, pero el primero (# 14242), no explica en la parte superior de qué se trata, aparte de que es una API de volumen (es decir, no estoy seguro de qué capacidades ofrece).

@sagiegurari es parte de los requisitos para implementar la gestión del volumen de imágenes (hay algunos otros problemas abiertos de relaciones públicas). El objetivo final es hacer de los volúmenes un ciudadano de primera clase en Docker, que se puede crear / eliminar / administrar por separado de los contenedores que los utilizan.

@swachter Gracias por publicar esa solución,

Solucionamos el problema del volumen con fugas con un truco sucio, ya que impedía que el demonio de la ventana acoplable se iniciara antes de que el servicio agotara el tiempo de espera en nuestros hosts de la ventana acoplable de alta rotación:

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 soluciona el problema sin eliminar las imágenes almacenadas previamente en caché.

¿Podemos discutir el problema de los volúmenes con fugas en otro número? Analizarlo aquí da la impresión de que es un problema del mapeador de dispositivos, mientras que no lo es.

@tomlux @rhvgoyal

¿Alguna vez llegó a una conclusión sobre lo que ocurre en la caja de CentOS 7? Mi host de la ventana acoplable es casi idéntico y estaba experimentando el mismo problema. Seguí hasta el punto en el que @rhvgoyal pidió ejecutar el comando thin_dump . Después, fui a iniciar el demonio de la ventana acoplable y no se iniciaba. Acabo de eliminar / var / lib / docker y reiniciarlo desde entonces, pero solo quería saber si se encontró una resolución, ya que yo (y otros) puedo encontrarla nuevamente.

[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

Encontré la fuente de mi problema. A pesar de cómo apareció, no estaba relacionado con los problemas del hilo. Simplemente se debe a un malentendido sobre cómo funcionaba Docker. Todos, los contenedores muertos aún conservaban el espacio en disco que habían asignado durante su ejecución. Solo tuve que quitar todas las carcasas del contenedor para liberar espacio en el disco. Recuerdo que esto aparece en este hilo, pero pensé que solo se consideran volúmenes montados, no el espacio en disco asignado por el contenedor.

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

@tomlux Este también puede haber sido su problema, ya que su salida de docker ps -a mostró varios contenedores Dead .

docker rm no libera espacio en disco del contenedor

boot2docker reciente en OS X VirtualBox. OS X completamente parcheado.

Estoy construyendo un contenedor gordo (47 GB) y tiene un problema que indica que debo reconstruir el contenedor. Así que detuve el contenedor e hice docker rm. Comprobación doble con docker ssh'df -h', encuentro que el uso del disco sigue siendo de 47 GB. El contenedor tiene 75 GB.

Por tanto, tendré que volver a matar la máquina virtual acoplable.

¿Podemos hacer esto?

@ awolfe-silversky, ¿se devuelve espacio en disco _dentro_ de la máquina virtual? Si está fuera de la máquina virtual, es posible que esto no esté relacionado.

@ awolfe-silversky también; ¿Quitaste la _imagen_ también? quitar solo el contenedor puede no ser de mucha ayuda si la imagen todavía está allí

@ awolfe-silversky, este problema es sobre devicemapper, y si está usando docker-machine / boot2docker, es mucho más probable que esté ejecutando aufs . También me pregunto si has docker rmi 'd tu gran imagen.

Vale la pena ejecutar docker images , y docker info para ver si las cosas realmente son tan terribles como lo haces sonar :)

(sí, si todavía tiene la máquina virtual y se elimina la imagen, entonces deberíamos abrir un nuevo problema y depurar más, ya que ha encontrado un caso de esquina extraño)

No eliminé la imagen. Es de un registro interno de Docker.
Usé un script awk para dimensionar las imágenes: un 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á sucio, pero sé que todos los tamaños de imagen están en MB.

Así es como estaba tratando de diagnosticar el 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

Ahora mismo tengo caja con 0 imágenes.
docker volume ls -qf dangling=true no muestra nada.
docker volume ls muestra muchos volúmenes que, por definición, están huérfanos, ya que no hay imágenes para poseerlos.
docker volume rm $(docker volume ls) muestra muchos de estos mensajes:

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

El directorio del asignador de dispositivos consume 30 GiG.
Docker versión 1.10.2, compilación 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)

Además, ¿por qué la instalación predeterminada utiliza la opción de almacenamiento 'fuertemente desaconsejada'?
¿Por qué no me lo dijeron en la instalación?

Tengo exactamente el mismo problema aquí en una instancia EC2 de Amazon Linux.

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

En los casos en los que instalo nuevas imágenes de la ventana acoplable de forma regular, la única solución es hacer lo siguiente:

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

Realmente no creo que algo así sea aceptable en un entorno de producción.

alguna información extra:

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

Como este error existe desde hace años y parece que aún no se ha cerrado, ¿podría incluir en la documentación de la ventana acoplable sobre devidemapper cómo destruir la seguridad de toda la información de la ventana acoplable?
quiero decir, en esta página: https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
poner algo como "Limpiar mapeador de dispositivos" y cómo hacerlo.

Intentaré hacer rm -rf / var / lib / docker pero no me siento cómodo haciéndolo. ¿Alguien puede decirme si es seguro?

Estoy usando gentoo linux en mi computadora portátil diaria e intenté docker para aprender, pero llenar mi disco y reinstalar todo el sistema no es una opción porque no es una máquina virtual y reinstalar gentoo lleva tiempo.

Gracias por tu trabajo.

@mercuriete En su máquina de desarrollo, simplemente desinstale la

@ ir-fuel: acabo de hacer eso y ahora tengo esto:

$ 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

Estoy usando service docker start

@ ir-fuel gracias, funciona bien. : +1:

Reinstalar Docker para liberar espacio en disco es la respuesta más ridícula que encontré mientras buscaba una solución para este problema. No solo es una pérdida de tiempo, ni siquiera está permitido en la mayoría de los entornos. Es una buena forma de que le paguen si trabaja por horas.

Estoy completamente de acuerdo. Es sorprendente que un producto como Docker continúe consumiendo espacio en disco sin nada que pueda hacer al respecto, excepto desinstalar / reinstalar.

Revisando este problema en otro momento para ver que nada ha cambiado. +1

Este problema está marcado como cerrado. Necesitamos una resolución. Sin solución alternativa, sin reconfiguración. ¿Cuál es el estado real y cuáles son los ajustes de configuración implicados? No es aceptable eliminar y volver a crear un nodo Docker de producción.

¿Y cuál es la alternativa? ¿Cómo hacemos para evitar esto?

Si no se recomienda utilizar esta función, ¿por qué es silenciosa y predeterminada?
¿uno? Si no te importa la gente que usa devicemapper, podría estar incluso bien
con este. ¡Pero infórmeselo al usuario! ¿Te das cuenta de la cantidad de
¿Dolor de cabeza que la gente tiene debido a esta increíble 'solución' que eligió?
El 23 de junio de 2016 a las 4:32 pm, "kpande" [email protected] escribió:

La solución es evitar el uso del controlador del mapeador de dispositivos de la ventana acoplable,
Desafortunadamente.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397, o silenciar
la amenaza
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Siempre hay rkt ...

El sarcástico inútil y perverso general es sin duda la razón por la que nadie de aguas arriba se preocupa por darte las respuestas adecuadas.

nadie te obligó a usar Docker.

Es como si Oracle le dijera a un desarrollador de Java que use PHP debido a un error de JVM. Eso tampoco es consistente con el discurso del ascensor aquí.

Hace tres años, Docker hizo que una tecnología esotérica del kernel de Linux llamada contenedorización fuera simple y accesible para todos.

Estoy seguro de que mucha gente está agradecida de que Docker despegó como lo hizo y eso no podría haber sucedido sin el voluntariado de la comunidad. Sin embargo, no debería ser tan difícil admitir que también tiene sus problemas sin dejar implícitamente la línea "Soy un colaborador ascendente, así que cállate y escucha" cada vez que alguien menciona un punto desagradable.

Espere. Reporté un problema, proporcioné los detalles de mi máquina y configuración,
que no estoy obligado a hacer. Ninguno de devteam respondió a mi error y a otros
informes en período de medio año. Ahora que expuse este hecho, llamas a mi comportamiento
¿malévolo? ¿Incluso es de código abierto? Estoy buscando un proyecto de Go en el que trabajar y
no será Docker, te lo doy. ¿Es este tu objetivo?
El 23 de junio de 2016 a las 16:45, "gregory gray" [email protected] escribió:

Si no se recomienda utilizar esta función, ¿por qué es silenciosa y predeterminada?
¿uno? Si no te importa la gente que usa devicemapper, podría estar incluso bien
con este. ¡Pero infórmeselo al usuario! ¿Te das cuenta de la cantidad de
¿Dolor de cabeza que la gente tiene debido a esta increíble 'solución' que eligió?
El 23 de junio de 2016 a las 4:32 pm, "kpande" [email protected] escribió:

La solución es evitar el uso del controlador del mapeador de dispositivos de la ventana acoplable,
Desafortunadamente.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397,
o silenciar el hilo
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

En primer lugar, si aún tiene este problema, abra una nueva edición;

Espere. Informé un problema

Respondiste sobre un problema cerrado de 3 años; Después de la discusión anterior, se resolvió el problema original. Su problema _ puede_ ser el mismo, pero necesita más investigación para estar seguro; los errores que está informando indican que en realidad puede ser otra cosa.

Realmente recomiendo abrir un nuevo número, no comentar un problema cerrado

proporcionó los detalles de mi máquina y configuración, que no estoy obligado a hacerlo.

No está _obligado_ a hacerlo, pero sin ninguna información para continuar, es poco probable que se resuelva. Por lo tanto, cuando informe un error, incluya la información solicitada en la plantilla:
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

Ninguno de devteam respondió a mis informes de errores y a otros en un período de medio año.

Si se refiere a "uno de los mantenedores", tenga en cuenta que hay casi 24.000 problemas y relaciones públicas, y menos de 20 mantenedores , muchos de los cuales hacen eso además de su trabajo diario. No todos los comentarios serán notados, especialmente si se trata de un tema cerrado.

Si no se recomienda usar esta función, ¿por qué es silenciosa y predeterminada?

Es el valor predeterminado si _aufs_, _btrfs_ y _zfs_ no son compatibles, puede encontrar la prioridad que se usa al seleccionar controladores; consulte el daemon / graphdriver / driver_linux.go . Todavía está por encima de la superposición, porque desafortunadamente hay algunos problemas restantes con ese controlador que pueden afectar a _algunas_ personas.

La selección automática de un controlador de gráficos es solo para "poner las cosas en marcha"; el mejor controlador para _su_ situación depende de _su_ caso de uso. Docker no puede tomar esa decisión automáticamente, por lo que la configuración depende del usuario.

Si no le importa la gente que usa devicemapper, podría estar de acuerdo con esto.

Al volver a leer la discusión anterior, veo que los encargados de mantenimiento del mapeador de dispositivos en sentido ascendente han analizado esto _múltiples veces_, tratando de ayudar a los usuarios que informan estos problemas y resolviendo el problema. El problema se resolvió para aquellos que lo informaron o, en algunos casos, dependió de que las distribuciones actualizaran las versiones de devicemapper. No creo que eso pueda considerarse "despreocupación".

Además, ¿por qué la instalación predeterminada utiliza la opción de almacenamiento 'fuertemente desaconsejada'?

La ejecución en dispositivos de bucle está bien para que la ventana acoplable se ejecute, y actualmente es la única forma de configurar el mapeador de dispositivos automáticamente. Para la producción, y para obtener un mejor rendimiento en general, use direct-lvm, como se explica en la sección devicemapper en la guía del usuario del controlador de almacenamiento.

¿Por qué no me lo dijeron en la instalación?

Eso está fuera del alcance de la instalación, de verdad. Si va a utilizar algún software en producción, debería ser razonable suponer que se familiariza con ese software y sabe lo que se necesita para configurarlo para su caso de uso. Algunos mantenedores incluso argumentaron si la advertencia debería emitirse. Linux no es un sistema operativo "tomados de la mano" (¿su distribución muestra una advertencia de que puede ocurrir una pérdida de datos si está usando RAID-0? ¿Si tiene puertos abiertos en su firewall?)

Profundamente reacio como soy, a resucitar una vez más este antiguo hilo, todavía no hay ningún consejo significativo sobre cómo solucionar este problema en una máquina existente que se encuentra con este problema.

Este es mi mejor esfuerzo en un tldr; para todo el hilo; Espero que ayude a otros que encuentren este hilo.

Problema encontrado

Su volumen tiene una cantidad significativa (y creciente) de espacio que está en /var/lib/docker y está usando ext3.

Resolución

No tienes suerte. Actualice su sistema de archivos o vea blowing docker away en la parte inferior.

Problema encontrado

Su volumen tiene una cantidad significativa (y creciente) de espacio que está en /var/lib/docker y usted _no_ está usando ext3 (por ejemplo, el sistema actualmente usa xfs o ext4)

Resolución

Es posible que pueda recuperar espacio en su dispositivo mediante los comandos estándar de la ventana acoplable.

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

Ejecute estos comandos:

docker volume ls
docker ps
docker images

Si no aparece nada en ninguno de estos, consulte blowing docker away en la parte inferior.

Si ve imágenes obsoletas, contenedores sin usar, etc., puede realizar una limpieza manual con:

# 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)

Esto debería recuperar gran parte del espacio del contenedor oculto en el mapeador de dispositivos.

Soplando Docker

¿No funcionó? No tienes suerte.

Tu mejor apuesta en este momento es:

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

Esto destruirá todas sus imágenes de Docker. Asegúrese de exportar los que desee conservar _antes_ de hacer esto.

En última instancia, lea https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-production; pero espero que esto ayude a otros que encuentren este hilo.

Si tiene problemas con el uso de los consejos anteriores, abra un nuevo ticket que aborde específicamente el problema que encuentre y enlace a este problema; no lo publique aquí.

rm -rf / var / lib / docker

También puede usar nuke-graph-directory.sh .

Después de eliminar los archivos como se indicó anteriormente, ya no puedo iniciar Docker:
02 de marzo 04:53:40 pmdc001b dockerd [29522]: Error al iniciar el daemon: error al inicializar el controlador gráfico: abrir / var / lib / docker / devicemapper / devicemapper / data: no existe tal archivo o directorio

Me encontré con este problema en CentOS 7.3 y no quería depurar los problemas de devmapper que existen durante más de 3 años, así que seguí esta guía de DC / OS, purgué los paquetes originales, cambié a overlayfs y todo parece funcionar bien ahora : https://dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/ (aunque tuve que modificar el comando ExecStart para la versión 17.03 de la ventana acoplable -> "dockerd --storage-driver = superposición ")

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

(Purgar volúmenes, imágenes y contenedores no ayudó. Eliminar cosas en / var / lib / docker generó el problema descrito por @ gdring2 )

Ejecutar docker system prune liberó mucho espacio en mis máquinas.

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

Bueno, esto es un poco ... patético.

En mi caso, encontré este problema después de desinstalar Docker y eliminar el directorio /var/lib/docker , por lo que no pude ejecutar el equivalente de service docker stop ... service docker start .

Descubrí que mi sistema no informaba el espacio al eliminar /var/lib/docker como liberado (tenía ~ 14 GB en lo que parecía un limbo).

La solución a esto es simplemente volver a cargar su sistema de archivos, en mi caso, simplemente reinicié y recuperé el espacio.

¡No puedo creer que siga siendo un problema! vamos chicos, todavía lo tengo

@ shahaf600 ¿qué versión de https://github.com/moby/moby/issues/3182#issuecomment -228298975

Sin detalles, no hay mucho que decir sobre su situación; su caso podría ser causado por un problema diferente, pero dando como resultado un resultado similar.

bueno

después de comprar una de estas piezas de basura y ver el estado de soporte, la devolví.

Ahí está tu primer problema @misterbigstuff ... ¿ compraste algo que es de código abierto?

y lo devolvió