Moby: Device-mapper ne libère pas d'espace libre sur les images supprimées

Créé le 12 déc. 2013  ·  206Commentaires  ·  Source: moby/moby

Docker prétend, via docker info avoir libéré de l'espace après la suppression d'une image, mais le fichier de données conserve sa taille initiale et le fichier fragmenté alloué pour le fichier backend de stockage de device-mapper continuera à croître sans limite au fur et à mesure sont attribués.

J'utilise lxc-docker sur Ubuntu 13.10:

Linux ergodev-zed 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Cette séquence de commandes révèle le problème:

Une augmentation de l'utilisation de l'espace docker pull stackbrew/ubuntu:13.10 rapporté docker info , avant:

Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-252:0-131308-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
WARNING: No swap limit support

Et après docker pull stackbrew/ubuntu:13.10 :

Containers: 0
Images: 3
Driver: devicemapper
 Pool Name: docker-252:0-131308-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 413.1 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.8 Mb
 Metadata Space Total: 2048.0 Mb
WARNING: No swap limit support

Et après docker rmi 8f71d74c8cfc , il renvoie:

Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-252:0-131308-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
WARNING: No swap limit support

Le seul problème est que le fichier de données s'est étendu à 414 Mo (849016 blocs de secteur de 512 octets) par stat . Une partie de cet espace est correctement réutilisée après la suppression d'une image, mais le fichier de données ne se réduit jamais. Et dans certaines conditions mystérieuses (pas encore capable de se reproduire), j'ai 291,5 Mio alloué qui ne peuvent même pas être réutilisés.

Mon dmsetup ls ressemble à ceci lorsqu'il n'y a aucune image installée:

# dmsetup ls
docker-252:0-131308-pool        (252:2)
ergodev--zed--vg-root   (252:0)
cryptswap       (252:1)

Et un du du fichier de données montre ceci:

# du /var/lib/docker/devicemapper/devicemapper/data -h
656M    /var/lib/docker/devicemapper/devicemapper/data

Comment puis-je demander à docker de récupérer de l'espace et pourquoi docker ne le fait-il pas automatiquement lorsque les images sont supprimées?

arestoragdevicemapper exexpert kinbug

Commentaire le plus utile

Profondément réticent comme je le suis, à ressusciter à nouveau ce fil ancien, il n'y a toujours pas de conseils significatifs sur la façon de contourner ce problème sur une machine existante rencontrant ce problème.

C'est mon meilleur effort à un tldr; pour le fil entier; J'espère que cela aidera les autres à trouver ce fil.

Problème rencontré

Votre volume a une quantité d'espace significative (et croissante) qui est en /var/lib/docker et vous utilisez ext3.

Résolution

Vous n'avez pas de chance. Mettez à niveau votre système de fichiers ou voyez blowing docker away en bas.

Problème rencontré

Votre volume a une quantité d'espace significative (et croissante) qui est en /var/lib/docker et vous _pas_ utilisez ext3 (par exemple, système utilisant actuellement xfs ou ext4)

Résolution

Vous pourrez peut-être récupérer de l'espace sur votre appareil à l'aide des commandes docker standard.

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

Exécutez ces commandes:

docker volume ls
docker ps
docker images

Si vous n'avez rien répertorié dans l'un de ceux-ci, voir blowing docker away en bas.

Si vous voyez d'anciennes images obsolètes, des conteneurs inutilisés, etc., vous pouvez effectuer un nettoyage manuel avec:

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

Cela devrait récupérer une grande partie de l'espace du conteneur caché dans le devicemapper.

Souffler docker

Cela n'a pas fonctionné? Vous n'avez pas de chance.

Votre meilleur pari à ce stade est:

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

Cela détruira toutes vos images de docker. Assurez-vous d'exporter celles que vous souhaitez conserver _avant_ de le faire.

En fin de compte, veuillez lire https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-production; mais j'espère que cela aidera les autres qui trouveront ce fil.

Si vous rencontrez des problèmes lors de l'utilisation des conseils ci-dessus, ouvrez un nouveau ticket qui résout spécifiquement le problème que vous rencontrez et établissez un lien vers ce problème; ne le postez pas ici.

Tous les 206 commentaires

+1, je suis très intéressé d'entendre une discussion sur ce sujet. Jusqu'à présent, ma stratégie a été

  • faites attention à ce que vous construisez / tirez
  • soyez prêt à épater votre / var / lib / docker: neutral_face:

@AaronFriel , sur quelle version de Docker êtes-vous? 0.7.1?

/ cc @regilero (lien également vers # 2276)

À partir d'un nouveau / 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

Ensuite, après docker pull busybox, il a un peu augmenté:

# 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'agrandit _pas_ le fichier, mais libère de l'espace dans le pool 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

Le fichier de bouclage ne grossit pas si nous téléchargeons à nouveau l'image:

# 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

Donc, il semble que nous ne parvenions pas à re-sparsifier le fichier de bouclage lorsque le périphérique thinp rejette un bloc.

Cependant, si je crée un fichier à l'intérieur de l'image fs du conteneur, il récupère l'espace dans le fichier de bouclage.
Ie j'ai fait ceci dans l'image 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

Cela a augmenté le fichier de données de 299M à 344M. Mais quand j'ai supprimé a_file.bin (et j'ai attendu un peu), il est revenu à 299M.

Donc, cela me semble être un bogue de devicemapper. C'est-à-dire qu'il transmet les rejets du périphérique thinp au périphérique sous-jacent, mais il ne les rejette pas lors de la suppression des périphériques thinp du pool.

Cela semble être un problème de noyau, je cherchais à le contourner en utilisant BLKDISCARD, mais j'ai échoué. Voir ces bogues pour quelques détails: https://bugzilla.redhat.com/show_bug.cgi?id=1043527

J'ai mis ma solution de contournement dans https://github.com/alexlarsson/docker/tree/blkdiscard , mais nous recherchons toujours si nous pouvons faire mieux que cela.

Avoir ce problème sur CentOS (2.6.32-358.23.2.el6.x86_64) avec Docker 0.7.0, ainsi. Vieux, mais le problème n'est pas isolé d'Ubuntu.

Même problème sur Arch GNU / Linux 3.12.6-1-ARCH, Docker version 0.7.2.

Existe toujours sur 0.7.0 sur CentOS.

Existe toujours en 0.7.2 sur ubuntu 12.04.3 LTS.

Une grande partie de l'espace est en docker/devicemapper/devicemapper/data et metadata , mais aussi en docker/devicemapper/mnt

C'est chouette que j'ai appris que vous pouvez voir les systèmes de fichiers de conteneurs dans docker/devicemapper/mnt/SOME_KIND_OF_ID/rootfs

mais ce n'est pas bien que mon disque dur soit presque complètement mangé et ne puisse être réparé que par rmdir -r docker .

Je rencontre un problème similaire lors de l'écriture du support docker pour rspec-system. Ma VM de test (hôte docker) a un lecteur de 8 Go et après avoir créé des images à plusieurs reprises sans les supprimer, mon lecteur se remplit. Mais après avoir supprimé toutes les images et tous les conteneurs, le lecteur est toujours plein à 100%. J'ai pensé que c'était une erreur ID-10T mais j'ai simplement abandonné et détruit la VM tous ensemble.

Existe toujours en 0.7.5 sur ubuntu 13.04.

Ce problème a été résolu par le PR # 3256 qui a récemment été fusionné. Ce correctif sera inclus dans une prochaine version.

Je ferme ce problème maintenant car le correctif a été fusionné avec master.

Remarque: ce n'est pas _ entièrement_ corrigé tant que vous n'exécutez pas également un noyau avec http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= 6d03f6ac888f2cfc9c840db0b965436d32f1816d dedans. Sans cela, le correctif de docker n'est que partiel.

Quel est le travail autour pour supprimer de l'espace. J'utilise rhel 6.5 et il faudra peut-être un certain temps pour obtenir le nouveau noyau.

Envoyé de mon iPhone

Le 21 janvier 2014, à 6 h 18, Alexander Larsson [email protected] a écrit:

Remarque: ce n'est pas entièrement résolu tant que vous n'exécutez pas également un noyau avec http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= 6d03f6ac888f2cfc9c840db0b965436d32f1816d dedans. Sans cela, le correctif de docker n'est que partiel.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub.

@logicminds Il n'y a pas de moyen très simple de récupérer l'espace atm. Techniquement, il devrait être possible de re-sparsifier manuellement les fichiers de bouclage. Mais cela exigerait que tous les blocs non utilisés soient remis à zéro ou quelque chose pour une détection facile des zones clairsemées, ce qui n'est pas fait lors du retrait de l'appareil thinp.

@alexlarsson Cela

@logicminds Je ne sais même pas si ce commit est encore dans le noyau en amont. Ce lien provient de l'arborescence du mappeur de périphériques. Ce n'est certainement pas en 3.8.

Je cherche à créer un outil comme fstrim qui peut être utilisé pour récupérer l'espace.

Le problème https://bugzilla.redhat.com/show_bug.cgi?id=1043527 a été fermé, officiellement en raison de "données insuffisantes". Cela signifie-t-il que le patch ne sera pas intégré au noyau? Est-ce encore nécessaire?

@vrvolle Le correctif qui apporte la solution de contournement

J'ai toujours ce problème avec docker 0.9 sur centos 6.5 avec le noyau 2.6.32 par défaut.

Je ne suis pas sûr de comprendre ce que vous avez dit précédemment à propos de ce commit dans device-mapper. Pourriez-vous confirmer que si je migre mon noyau vers la version 3.8, ce bogue devrait être résolu?

Merci d'avance.

@ nicolas-van Non, vous avez besoin de ce commit: https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316

Il est en 3.14, et peut être dans divers backports 3.xy

J'ai installé il y a quelque temps docker pour créer une image et l'exécuter dans un conteneur. Puis quelque temps plus tard, j'ai effacé toutes les images et tous les conteneurs, y compris l'application docker et le dossier principal.
Maintenant, je me rends compte que sur un total de 4 Go / 24 Go libres / utilisés (df -h), la commande du / -sh rapporte seulement 10 Go, donc 10 Go supplémentaires ne sont pas pris en compte. C'est plus moins la taille des images temporaires générées avec docker, cela pourrait-il être lié à ce bogue. J'ai utilisé centos 6.5 et docker 0.9.

J'ai supprimé docker avec yum et devs de / dev / mapper / docker * avec dmsetup, ainsi que rm / var / lib / docker -Rf, et le disque rapporte toujours avec df 10gb utilisé que je ne trouve nulle part.

@Jacq Il est possible qu'un certain fichier soit toujours maintenu en vie par un processus qui a un descripteur de fichier ouvert. Avez-vous redémarré? Cela garantirait que cela ne se produise pas.

Je lance Linux 3.14.4-1-ARCH et docker 0.11.1, j'ai supprimé toutes les images et tous les conteneurs.
et le fichier / var / lib / docker / devicemapper / devicemapper juste coincé, consommant environ 1,5 Go

voici la sortie après avoir joué avec des trucs mongodb, je suppose que la taille du fichier doit être allouée de manière clairsemée car mon / var n'est même pas si grand.

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

Excusez-moi, le bogue est-il corrigé maintenant? Je l'ai rencontré dans Gentoo.

@bolasblack Je lance gentoo et j'ai rencontré ce problème. Avez-vous trouvé quelque chose?

J'utilise les dernières gentoo-sources qui sont 3.14.14 pour x86_64. J'ai regardé https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316?diff et ce correctif est appliqué à mes sources. J'ai docker Docker version 1.1.0, build 79812e3.

@alexlarsson Merci d'avoir attiré votre attention sur ce problème clos après une si longue période. Il semble que cela cause toujours des problèmes. Un mot sur le statut du # 4202?

C'est toujours un problème! Je pense que je vais revenir à l'utilisation de AUFS pour le moment.

@daniellockard AUFS semble être officieusement obsolète: # 783 et # 4704, alors bonne chance avec ça.

Yikes ... où sont passés ces 25 Go? Oh, dans ce seul fichier ... J'utilise le noyau 3.16.2 f20 64b

Le lien vers la «solution de contournement» est rompu ... qu'est-ce que c'est? et est-ce que mon noyau le prend en charge ... si Torvalds s'est engagé en 3.14, je suppose que fedora devrait le voir en 3.16, non?

+1

+1

+1

+1 Semble encore se produire sur Ubuntu Trusty, 3.13.0-36-generic avec Docker version 1.3.1, build 4e9bbfa

+1 également sur Trusty. Vaut-il la peine de vérifier sur 14.10 qui utilise 3.16?

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

Marquer les meilleurs committers parce que c'est ridicule. Il doit y avoir une conversation publique à ce sujet et une admission de l'équipe de Docker que ce bogue peut conduire à des conteneurs ou des systèmes qui se cassent périodiquement et doivent être recréés. Je connais déjà plusieurs personnes qui ont dû implémenter des solutions devops insensées, comme la réimagerie périodique de leurs hôtes Docker toutes les semaines ou deux, car leurs robots de construction ont tellement de taux de désabonnement. J'ai introduit ce problème il y a près d'un an et, pour autant que je sache, aucune solution définitive n'a été créée, et les noyaux plus anciens qui sont apparemment pris en charge ne le sont pas.

Équipe Docker: veuillez faire des recherches pour déterminer quelles versions du noyau sont concernées, pourquoi et quel correctif résoudra le problème, et documentez-le. Publiez ces informations avec les versions de noyau que vous prenez en charge, car à l'heure actuelle, les consommateurs de Docker ne cessent de se faire mordre par ce problème, comme en témoigne le fait que je reçois toujours des e-mails sur ce problème toutes les semaines ou deux. Sérieusement, c'est un problème majeur et c'est un problème depuis avant la version 1.0.

À mon avis, il existe plusieurs options possibles pour résoudre ce problème de manière satisfaisante, ce qui arrêterait les e-mails que je continue de recevoir pendant des +1 sur ce problème:

  1. Avertissez les utilisateurs lorsque Device-Mapper est utilisé sur un noyau non pris en charge et fournissez-leur des instructions détaillées sur la façon de récupérer de l'espace et, si possible, configurez automatiquement un processus pour le faire dans Docker. Je conseillerais que cet avis soit également émis lors de l'utilisation de la CLI docker contre un hôte qui souffre de ce problème, de sorte que lors de la gestion à distance des hôtes à partir de la CLI docker, les utilisateurs soient informés que certains hôtes peuvent ne pas récupérer correctement l'espace.
  2. Résolvez le problème (en quelque sorte). Je n'en sais pas assez sur le développement du noyau pour savoir ce que cela impliquerait, mais, sur la base de mes lectures novices, je suggère ceci:

une. Comme le mappeur de périphériques est un module du noyau, apportez une version fonctionnelle et fonctionnelle de celui-ci dans l'arborescence des sources de Docker comme quelque chose comme dm-docker

b. Apportez des modifications suffisantes à dm-docker pour qu'il puisse coexister avec le mappeur de périphériques.

c. Sur les plates-formes concernées, installez le module noyau dm-docker lors de l'installation et utilisez par défaut dm-docker .

  1. Modifiez vos documents d'installation et le site docker.com pour inclure un avertissement sur les versions de noyau affectées, et ajoutez une vérification d'exécution aux packages pour vérifier le bon fonctionnement du mappeur de périphériques, et si ce n'est pas le cas, signalez-le à l'utilisateur.

Cela devrait être un problème de blocage pour la prochaine version stable de Docker, car il est tout simplement inacceptable de continuer à le faire et de laisser les utilisateurs dans l'embarras.

Personnellement, je vois le CoreOS comme la seule distribution Linux stable pour Docker (jusqu'à ce que ce problème soit résolu).

Docker Team: Je sais que ce problème n'est pas causé par votre composant, mais s'il vous plaît, aidez-nous à utiliser votre logiciel également sur les autres distributions Linux. Ce serait bien si vous pouviez également mentionner ce problème comme une limitation bien connue de Docker dans la documentation, afin que d'autres personnes ne perdent pas leur temps.

Merci!
Martin

+1 quelque chose doit être fait.

Ce serait bien s'il y avait quelque chose de plus apparent pour ce problème que de devoir fouiller dans la liste (fermée) des problèmes de github. Il a fallu beaucoup de temps pour découvrir que c'était le problème sous-jacent et il aurait été agréable d'avoir une visibilité sur ce problème.

Nous, les développeurs de mappeurs de périphériques en amont (moi-même et Joe Thornber), étions absolument conscients que ce problème est toujours un problème pour les gens. Nous avons résolu le problème immédiatement une fois que nous en avons été informés (par @alexlarsson en décembre 2013) et l'avons marqué pour inclusion dans _all_ noyaux stables à ce moment-là, voir: http://git.kernel.org/linus/19fa1a6756ed9e9 ( "dm thin: correction de la prise en charge du rejet d'un bloc précédemment partagé")

Joe Thornber vient juste d'être informé que @alexlarsson a implémenté trim-pool dans le code go de docker. Quand je lui ai fait remarquer, il a commencé à implémenter un outil autonome approprié 'thin_trim' qui sera distribué dans le cadre du package 'device-mapper-persistent-data' (au moins sur Fedora, CentOS, RHEL), voir:
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

Donc ... tout cela étant dit, les utilisateurs qui exécutent des noyaux qui n'ont pas de commit amont 19fa1a6756ed9e9 ("dm thin: fix discard support to a précédemment shared block") doivent corriger cela en exécutant des noyaux mieux supportés. Je peux facilement envoyer une note à [email protected] pour

À l'avenir, nous voudrons que docker exécute périodiquement 'thin_trim' sur le périphérique de pool léger que docker utilise. Mais nous traverserons ce pont une fois que «thin_trim» sera largement disponible dans les distributions.

@shabbychef @daniellockard non, les AUF ne sont pas obsolètes - d'abord, un seul de ces problèmes est fermé, et en lisant, je suppose que https://github.com/docker/docker/issues/783#issuecomment -38731137 est à lire:

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 pourriez-vous ajouter quelque chose à hack/check_config.sh pour dire aux utilisateurs que leur noyau n'a pas ce correctif?

@SvenDowideit, malheureusement, le changement en question n'est pas identifié dans un noyau arbitraire. Pour commencer, le commit 19fa1a6756ed9e9 n'a pas modifié la version des cibles thin ou thin-pool. Mais même si c'est le cas, cette version variera à travers tous les noyaux stables (et c'est pourquoi les changements de version dans un commit «stable» sont mauvais ... car cela cause une édition manuelle de tous les noyaux sur lesquels le commit est rétroporté).

MAIS, les utilisateurs qui ont une version cible thin et thin-pool> = 1.12.0 auront tous le correctif. Donc les noyaux> = 3.15. Le docker que les utilisateurs exécutent devrait également inclure le commit 0434a2ce de

Pour info, l'exécution de 'dmsetup cibles' listera les versions cibles thin et thin-pool (à condition que le module de noyau dm-thin-pool soit chargé).

Merci pour votre attention à ce sujet. Nous l'avons mentionné aux mecs du stand de Re: Invent la semaine dernière.

@snitm donc la dmsetup targets doit être ajoutée à la sortie check-config ?

@snitm

Serait-il possible de créer un test automatisé qui créerait un périphérique de mappage de périphériques à allocation dynamique, effectuerait des opérations sur celui-ci qui échoueraient à récupérer de l'espace libre sur un noyau non corrigé, et rapporterait un code d'état basé sur cela?

@SvenDowideit vous

@AaronFriel semble extrêmement restreint dans sa portée pour être tellement accroché à ce correctif particulier. Il y a plus à déployer au niveau de l'entreprise du Thin Provisioning DM que de s'assurer que ce correctif est en place (malheureuse réalité). La cible de provisionnement léger DM a connu de nombreuses améliorations en matière de gestion des erreurs, de performances et de fonctionnalités depuis que le commit 19fa1a675 est passé en amont. Tous ces éléments sont importants lors du déploiement du Thin Provisioning DM en production.

Donc, en prenant du recul, il se trouve que je peux aimer travailler pour une entreprise qui comprend que les produits en couches doivent être développés de concert avec toutes les couches sous-jacentes. Et je n'ai guère d'intérêt à prendre en charge le provisionnement fin DM pour N noyaux arbitraires associés à docker.

Et je crois fermement que personne ne devrait utiliser le provisionnement léger DM avec des périphériques de bouclage comme périphériques de support. C'était un hack complet qui a été fusionné dans docker sans contrainte ni souci de "à quoi cela ressemble-t-il en production?".

J'ai réalisé qu'un déploiement correct de docker sur le provisionnement léger DM nécessite les fonctionnalités de gestion orientées entreprise fournies par la configuration de provisionnement léger basé sur lvm2. Donc, dans cet esprit, j'ai travaillé régulièrement pour faire fonctionner une nouvelle solution de gestion hybride, voir ce PR:
https://github.com/docker/docker/pull/9006

Ce travail dépend de:
1) lvm2> = 2.02.112
2) Version cible DM thin-pool> = v1.14.0 (alias changements mis en scène dans linux-next pour l'inclusion de Linux 3.19)

RHEL7.1 aura ces changements. Et RHELAH (Atomic Host) le sera aussi. Toutes les autres distributions / produits qui souhaitent déployer correctement docker sur le provisionnement léger DM devraient également.

@snitm ouais - j'essaie de réduire le nombre d'utilisateurs qui sont touchés par une cassure mystérieuse, ce qui prend alors encore plus de temps pour que quelqu'un se rende compte que cela pourrait être cette douleur obscure, puis d'essayer de demander à l'utilisateur de comprendre qu'un manque de patch mystère est le problème.

et donc dans le contexte de vos informations restantes - je veux réduire le nombre de noyaux qui provoqueront cette horrible surprise :)

@SvenDowideit OK, j'ai fourni les informations que docker (ou ses utilisateurs) pourrait utiliser pour vérifier DM thinp sur la compatibilité de bouclage dans ce commentaire: https://github.com/docker/docker/issues/3182#issuecomment -63706507

@snitm , @AaronFriel
Je rencontre ce qui semble être ce problème sur AWS beanstalk, Amazon AMI.
(Manque d'espace)
Linux ip-172-31-63-145 3.14.23-22.44.amzn1.x86_64 # 1 SMP mar.11 novembre 23:07:48 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux

$ sudo version docker
Version du client: 1.3.2
Version de l'API client: 1.15
Version Go (client): go1.3.3
Git commit (client): c78088f / 1.3.2
OS / Arch (client): linux / amd64
Version du serveur: 1.3.2
Version de l'API serveur: 1.15
Version Go (serveur): go1.3.3
Git commit (serveur): c78088f / 1.3.2

J'obtiens toujours cette erreur avec Ubuntu 14.04 et Docker 1.4.1.

Ne comptez pas sur les versions thin-pool et thin> = 1.12.0 pour signifier que vous êtes OK Nous exécutons des machines virtuelles CentOS 6.5 avec le noyau 2.6.32-431.29.2.el6.x86_64 et les cibles dmsetup signalent que thin-pool et thin sont tous deux v1.12.0. Cependant, je suis coincé avec un fichier de données de 40 Go qui ne se libère pas.

Quelles sont les implications de l'exécution sur CentOS / RHEL 6.5 avec ce bogue? Êtes-vous d'accord avec> = 100G d'espace libre. Je suppose que cela remplit finalement n'importe quel disque de taille? Ou est-il limité à 100G?

Gardez à l'esprit que la version 6.5 n'a pas le dernier noyau disponible pour centos. Je recommanderais une simple mise à jour «yum» vers 6.6 et un redémarrage pour tester avec le noyau 2.6.32-504.3.3.

Vérifiez que les toutes dernières mises à jour du noyau et de la distribution pour CentOS 6 fonctionnent correctement et libèrent de l'espace.

ripienaar: Pouvez-vous indiquer explicitement quelle version de CentOS 6 et du noyau vous utilisez? Je veux juste m'assurer que lorsque je transmets les informations, je dispose de toutes les informations dont j'ai besoin.

Merci.

Comme @reiz l'a commenté ci-dessus, cela se produit avec le dernier docker Ubuntu 14.04 +. Les cibles dmsetup affichent le thin / thin-pool de v1.9.0 sur l'une de nos instances (aucun conteneur docker actif.) Les cibles dmsetup ne montrent aucune entrée fine sur une instance similaire avec des conteneurs docker actifs. (Je ne demande pas vraiment d'aide à ce sujet, j'ajoute simplement des données (espérons-le utiles).)

Matériel de base du système d'exploitation:

# 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

Usage:

# 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

Avant d'accéder à ce noyau, il ne récupérait pas d'espace.

@jperrin mentionne que cela doit être résolu en utilisant le noyau centos 2.6.32-504.3.3. sait-on quel noyau commit (ensemble de commits?) qui résout ce problème?

J'utilise actuellement l'un des UEK Oracle Enterprise Linux 3.8.

Existe-t-il une solution de contournement pour cette situation? chez AWS, il est facile de simplement recréer l'instance, mais dans l'environnement de développement local, il n'est pas bon de remarquer que la partition / var est détenue à 90% par le mappeur de périphériques en raison de docker; bientôt plus d'espace même pour les journaux ou les journaux

@donrudo comme ci-dessus - mise à jour vers le dernier centos 6 - le noyau 504.3.3.

C'est correct pour les centos, mais certains de nos développeurs utilisent Fedora et d'autres OpenSuse.

Toutes les modifications de l'allocation dynamique DM sont envoyées en amont en premier. Donc, si Centos 6 est fixe, il l'est également en amont. Les différentes distributions doivent retirer des correctifs ou rebaser de manière plus agressive.

@ripienaar Je vais demander à nouveau, savez-vous quel noyau de commit (ou ensemble de commits) est requis pour le correctif?

@lexinator non

Je vois ce problème sur Ubuntu 14.04 Trusty et le noyau 3.13.0-36-generic. La solution possible consiste à attacher le stockage AWS EBS au répertoire afin qu'il puisse évoluer indéfiniment.

Les gars, ce problème fait vraiment mal. CoreOS passe maintenant à ext4 et nous aurons bientôt tous ces problèmes sur CoreOS.

Comment les gens peuvent-ils utiliser Docker (en développement ou en production) alors que ce problème n'est pas résolu pendant plus d'un an? Tout le monde a des disques sans fin?

Je crois qu'ils se déplacent vers ext4 pour la superposition et non pour le devmapper. Mais c'est
juste le mot dans la rue ...

Le mercredi 28 janvier 2015, Sergey [email protected] a écrit:

Les gars, ce problème fait vraiment mal. CoreOS passe maintenant à ext4 et bientôt nous
aura également tous ces problèmes sur CoreOS.

Comment les gens peuvent utiliser Docker (en développement ou en production) alors que ce problème n'est pas résolu pour
plus d'un an? Tout le monde a des disques sans fin?

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/docker/issues/3182#issuecomment -71800923.

Je suis confus. Mon espace disque sur une instance Google n'est que de 10G, mais la taille de / var / lib / docker / devicemapper / devicemapper / data est affichée comme 100G. Je ne suis pas en mesure de récupérer de l'espace même après avoir supprimé tous les conteneurs et images.

C'est un fichier clairsemé. Utilisez ls -sh au lieu de ls -l , ou alternativement du -h

Je peux signaler cela sur Ubuntu 13.04 (probablement pas surprenant).

La seule véritable solution de contournement à ce problème est-elle actuellement de fournir suffisamment d'espace disque pour anticiper la croissance de devicemapper?

Tout ce fil est assez ridicule. Un utilisateur Debian après l'autre se plaint. Si vous rencontrez un problème, vous devez soit passer à une distribution correctement maintenue, soit travailler avec les responsables de votre distribution pour les amener à résoudre le problème. Ces distributions ne suivent pas les correctifs ou les améliorations. J'ignorerai toutes les futures plaidoiries pour que quelqu'un corrige ce problème sur la distribution $ foo étant donné que le correctif est déjà clairement en amont (voir CentOS ou RHEL). Veuillez ouvrir un bogue contre la distribution défectueuse en question et faire référence à ce problème.

Ce n'est pas si ridicule que Docker affirme avoir un support sur les plates-formes suivantes:

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)

Comment pouvez-vous avoir un appel de support général pour 14.04 alors que ce problème est manifestement si répandu. Docker devrait évidemment abandonner la prise en charge globale de certains noyaux sur certaines distributions.

J'utilise CentOS et la mise à niveau du noyau semble avoir amélioré le problème d'utilisation du devicemapper.

Quoi qu'il en soit, merci pour votre travail @snitm.

Pour ceux qui rencontrent ce problème sur Ubuntu, assurez-vous que vous nettoyez correctement les anciennes images / conteneurs du docker. J'ai constaté que mon script de nettoyage ne fonctionnait pas quand je le pensais, et c'est pourquoi il utilisait autant d'espace.

`` #! / bin / bash

Supprimer tous les conteneurs

docker rm $ (docker ps -a -q)

Supprimer toutes les images

docker rmi $ (images de docker -q)
''

@TylerMills note que docker rm ne supprimera _pas_ les volumes créés par les conteneurs. Si vos conteneurs utilisent des volumes, vous devez utiliser docker rm -v pour que docker supprime également les volumes.

@snitm Nous venons de nous en dire plus (en utilisant Ubuntu 14.04). Bien que ce ne soit peut-être pas spécifiquement la faute de Docker, ils devraient avoir un grand intérêt à résoudre ce problème, car cela reflète mal l'expérience dans son ensemble.

Notez également que j'ai rencontré ce problème et voici ce que j'ai fait pour le résoudre:

Dans mon cas cependant, en raison du périphérique sur lequel / var est monté sur une utilisation à 100%, le seul moyen d'empêcher l'hôte d'entrer dans une panique du noyau est de tuer directement le processus docker (c'est-à-dire que l'émission de toute commande docker paniquerait).

Ensuite, supprimez manuellement tous les processus à l'aide des montages de devicemapper en utilisant cette commande:

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

alors j'ai pu démonter n'importe quel support de devicemapper en utilisant:

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

ces étapes ont libéré tous les descripteurs de fichiers qui m'ont permis de récupérer l'espace / supprimer des fichiers quoi que ce soit.

À ce stade, dans mon cas, il était plus logique de déplacer le répertoire / var / lib / docker vers un montage avec plus d'espace et de configurer le démon docker pour utiliser un répertoire de base différent en utilisant l'argument -g

merci à Alexander Larsson via Adam Miller

Suite au commentaire de @dekz , ce serait probablement une bonne idée si le guide d'installation n'indiquait pas aux utilisateurs que les versions du noyau sans ce correctif sont acceptables comme cela est fait ici: https://docs.docker.com/installation/ubuntulinux/

Merci @JohnMorales. Un petit avertissement à ce sujet de Docker serait une excellente idée.

+1

+1

Nous avons récemment eu un peu de mal à utiliser Ubuntu 14.04.2 LTS (3.16.0-30-generic) et sommes toujours en train de chercher une solution. Il semble que le passage à CentOS 6.6 (qui a supposément le correctif du noyau) ou le montage d'un volume avec un disque plus grand soient les seules solutions.

Quelqu'un exécutant Ubuntu a-t-il trouvé une solution de contournement acceptable?

Je suis d'accord - Docker devrait gérer et résoudre ce problème - c'est un bogue sérieux qui nécessite de la documentation et des messages d'avertissement, donc plus de gens ne tombent pas naïvement dans le même piège.

Je suis d'accord avec @natea
Je suis confronté au même problème avec redhat 6.5 et cela pose un gros point d'interrogation si docker est prêt pour la production et que nous commençons à chercher des alternatives.
Cela ne me dérange même pas d'obtenir une solution de contournement manuelle pour résoudre le problème, mais pour le moment, je ne suis au courant d'aucune solution réalisable.

@sagiegurarie sachez que nous avons repoussé les exigences de CentOS à 6.6 en raison de divers problèmes avec 6.5 (et le noyau associé). Cette exigence n'est probablement pas encore sur le site Web de la documentation en direct, mais le sera avec la prochaine version, peut-être avant cela.

La réponse à la question n ° 11643 n'est donc pas pertinente? cela signifie que nous ne pouvons pas utiliser redhat 6.5?

@natea @sagiegurari Ce qui fonctionne pour nous, c'est le "correctif" manuel suggéré par @TylerMills

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

L'inconvénient, bien sûr, est que vous devez ensuite extraire toutes les images et exécuter à nouveau les conteneurs.

@bkeroackdsc Je me souviens que j'avais également supprimé tous les conteneurs et images auparavant et cela ne l'a pas résolu, mais je vais essayer de nouveau.

salut! Je voudrais savoir si ce problème existe toujours sur ubuntu-15.04. Qui est maintenant au noyau linux-3.19. Merci beaucoup.

si vous êtes sur ubuntu-15.05 avec ce noyau, pourquoi ne pas utiliser de superposition, c'est bien
mieux que devicemapper

Le jeudi 7 mai 2015 à 11 h 26, Dreamcat4 [email protected] a écrit:

salut! Je voudrais savoir si ce problème existe toujours sur ubuntu-15.04.
Qui est maintenant au noyau linux-3.19. Merci beaucoup.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99968299.

@jfrazelle Oh c'est vrai. De quoi ça a l'air? Utilisez-vous la superposition? Je suis parti de l'hypothèse (jusqu'à présent) que le support de la superposition était encore expérimental à partir du noyau 3.19.

Oui, j'utilise la superposition :) nous espérons le faire monter dans la liste 1.7 perdu de nous
utilise-le et aime-le

Le jeudi 7 mai 2015, Dreamcat4 [email protected] a écrit:

@jfrazelle https://github.com/jfrazelle Oh c'est vrai. De quoi ça a l'air? Faire
vous utilisez la superposition? Je suis parti de l'hypothèse (jusqu'à présent) que
le support de la superposition était encore expérimental à partir du noyau 3.19.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99982543.

@sagiegurari Pourquoi

@jperrin parce que ce n'est pas ma décision :)
en tout cas j'essaye de vérifier avec toutes les équipes pour voir si redhat 7 serait ok pour la production.

Cela semble toujours être un problème sur CentOS7 (3.10.0-123.el7.x86_64). J'ai configuré une nouvelle boîte CentOS et installé le docker v1.6.0. Le fichier de données devicemapper ne diminue jamais la taille après un sudo docker rmi. Je cherche à obtenir une boîte CentOS6.6 pour l'essayer.

La v1.6.0 sur Ubuntu 14.04 semblait avoir un effet positif (par rapport à la v1.5.0)

semble également bien fonctionner sur centos 7, ce que je suppose que je peux également dire pour redhat 7
mais redhat 6.5 ne l'est pas, et je suggère de l'indiquer dans la documentation.

Cela devrait fonctionner dans le dernier docker en amont. Et le dernier commentaire de @sagiegurari semble impliquer cela. (fonctionne sur centos 7).

Si tel est le cas, nous devrions fermer ce bogue.

Alors, ce problème se produit-il toujours avec le dernier docker? Sinon, fermons-le.

bien .... exécuter plus de tests semble fournir des résultats incertains.
disons que c'est beaucoup mieux, mais pourrait encore fuir, juste beaucoup plus lentement.
Je vais exécuter plus de contrôles pour confirmer.

@sagiegurari

Pouvez-vous me donner plus de détails sur le problème auquel vous êtes confronté et sur votre environnement. Le titre du problème indique que l'espace n'est pas récupéré lors de la suppression de l'image / du conteneur, et le dernier docker en amont ne devrait pas avoir de tels problèmes.

Pouvez-vous s'il vous plaît prendre le docker en amont, créer un binaire dynamique, créer un nouveau répertoire thin pool (dans un nouveau répertoire / var / lib / docker /), extraire une image, la supprimer et regarder les informations du docker et voir si de l'espace a été libéré ou ne pas.

J'espère exécuter plus de tests la semaine prochaine pour fournir des informations plus exactes.

J'avoue que je le vois dans notre machine de construction où nous créons et supprimons beaucoup d'images (pendant la construction elle-même) + exécutons le registre docker 2.0 (auquel nous poussons toujours les différentes images avec la balise `` latest '') + exécutons quelques conteneurs vers faites des tests initiaux pour que tout fonctionne correctement (le test n'est en fait pas censé fonctionner sur cette machine, mais nous en sommes au début, nous créons / arrêtons / rm un grand nombre de conteneurs).

nos images sont vraiment grandes, parfois je vois une taille virtuelle supérieure à 2 Go, donc s'il y a un problème, cela se montre plus rapidement qu'avec des images habituelles qui sont normalement autour de 400 mg.

de toute façon, j'essaierai d'exécuter quelques tests pour voir le comportement et fournir plus de détails la semaine prochaine.

En utilisant Docker version 1.6.0, compilez 4749651 / 1.6.0 sur le noyau Linux 3.14.35-28.38.amzn1.x86_64

La suppression d'images réduit l'espace disque réclamé par le docker.

@vbatts

Pouvons-nous fermer ce problème? Je ne pense pas que dans le dernier docker, nous ayons le problème de récupérer l'espace image / conteneur à partir de fichiers OOP. Si quelque chose de spécifique se produit, on peut ouvrir un nouveau problème avec des détails spécifiques.

@rhvgoyal Je ne vois pas de raison de se précipiter et de fermer ce problème après que tant de gens se plaignent de tant de plates-formes / versions.

@sagiegurari

Je ne sais pas ce que nous gagnons à garder la question ouverte. Je sais que c'est réglé en amont. Il y a tellement de problèmes qui sont ouverts. Les gens les utilisent comme tableau de bord pour noter les observations.

Je pense que garder un problème ouvert n'a de sens que s'il y a un réel problème reproductible. Sinon, cette liste de problèmes ne cesse de s'allonger et il est difficile de savoir sur lequel se concentrer.

Personne ne vous empêche d'ajouter plus de données à ce problème une fois que vous l'avez.

@rhvgoyal à quel tag faites-vous référence par le dernier en amont?

@rhvgoyal Dites le dernier commit. Je viens de cloner le dernier arbre git et de le tester. Est-ce que c'est vraiment important?

Tant de problèmes sont signalés sur les anciennes versions de docker et les anciens noyaux. Je pense que la première étape devrait être de voir si le même problème est visible sur le dernier docker et le kernerl relativement plus récent. Cela nous donne une idée s'il s'agit toujours d'un problème ou de quelque chose qui n'est pas résolu dans les anciennes versions.

Quand quelqu'un revient et le lit dans le futur, oui. Je voulais savoir dans quelle version il était corrigé.

Nous émettons des rejets dans le cas de périphériques de bouclage. Cela a été fait il y a longtemps en fait. Je pense que 1.6 devrait l'avoir.

@stanislavb a testé avec 1.6 et cela a fonctionné pour lui.

Si vous vous référez à mon premier commentaire dans ce numéro, vous verrez que j'ai également essayé avec la v1.6.0 sur centos7 et que j'avais toujours le problème.

@alexDrinkwater

Ok, pouvez-vous le reproduire? Quel type de piscine mince avez-vous utilisé (au-dessus des périphériques en boucle?). Avez-vous redémarré docker ou cela se produit la première fois que vous démarrez docker?

Dans certains cas, il peut arriver que le docker utilise des périphériques en boucle, puis que le docker soit redémarré, il peut arriver que le pool n'ait pas été arrêté car un périphérique était occupé quelque part. Au redémarrage du docker
trouve le pool déjà là et ne sait pas que les périphériques de bouclage sont utilisés et il n'émet pas de rejet. Je me demande si vous avez couru dans cette situation?

CentOS 7

Docker version 1.6.2.el7, build c3ca5bb / 1.6.2

Avant le nettoyage de l'image

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

Après quelques rmi docker

[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, tout à l'heure j'ai démarré une image centos7 et essayé docker 1.6 et je ne vois pas le problème. Voici les étapes.

[ root @ centos7-generic ~] # version de docker
Version du client: 1.6.0
Version de l'API client: 1.18
Version Go (client): go1.4.2
Git commit (client): 8aae715 / 1.6.0
OS / Arch (client): linux / amd64
Version du serveur: 1.6.0
Version de l'API serveur: 1.18
Version Go (serveur): go1.4.2
Git commit (serveur): 8aae715 / 1.6.0
OS / Arch (serveur): linux / amd64

Il y a déjà une image importée.

[ root @ centos7-generic ~] # images docker
RÉPERTOIRE TAG IMAGE ID CRÉÉ TAILLE VIRTUELLE
docker.io/fedora dernière ded7cd95e059 il y a 2 semaines 186,5 MB

Voici la sortie des informations du docker.

root @ centos7-generic ~] # info sur le docker
Conteneurs: 0
Images: 2
Pilote de stockage: devicemapper
Nom de la piscine: docker-253: 1-50331788-pool
Taille des blocs de piscine: 65,54 kB
Système de fichiers de sauvegarde: xfs
Fichier de données: / dev / loop0
Fichier de métadonnées: / dev / loop1
Espace de données utilisé: 525,5 Mo
Espace de données total: 107,4 Go
Espace de données disponible: 20 Go
Espace de métadonnées utilisé: 892,9 kB
Espace de métadonnées total: 2,147 Go
Espace de métadonnées disponible: 2,147 Go
Udev Sync pris en charge: vrai
Fichier de boucle de données: / var / lib / docker / devicemapper / devicemapper / data
Fichier de boucle de métadonnées: / var / lib / docker / devicemapper / devicemapper / metadata
Version de la bibliothèque: 1.02.93-RHEL7 (2015-01-28)
Pilote d'exécution: native-0.2
Version du noyau: 3.10.0-229.el7.x86_64
Système d'exploitation: CentOS Linux 7 (Core)
Processeurs: 2

[ root @ centos7-generic ~] # docker rmi fedora
Non étiqueté: fedora: dernier
Supprimé: ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4
Supprimé: 48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731

[ root @ centos7-generic ~] # infos sur le docker
Conteneurs: 0
Images: 0
Pilote de stockage: devicemapper
Nom de la piscine: docker-253: 1-50331788-pool
Taille des blocs de piscine: 65,54 kB
Système de fichiers de sauvegarde: xfs
Fichier de données: / dev / loop0
Fichier de métadonnées: / dev / loop1
Espace de données utilisé: 307,2 Mo
Espace de données total: 107,4 Go
Espace de données disponible: 20,22 Go
Espace de métadonnées utilisé: 733,2 kB
Espace de métadonnées total: 2,147 Go
Espace de métadonnées disponible: 2,147 Go
Udev Sync pris en charge: vrai
Fichier de boucle de données: / var / lib / docker / devicemapper / devicemapper / data
Fichier de boucle de métadonnées: / var / lib / docker / devicemapper / devicemapper / metadata
Version de la bibliothèque: 1.02.93-RHEL7 (2015-01-28)
Pilote d'exécution: native-0.2
Version du noyau: 3.10.0-229.el7.x86_64
Système d'exploitation: CentOS Linux 7 (Core)
Processeurs: 2

Remarque L'utilisation des données est passée de 525 Mo à 307 Mo. Donc, la suppression d'une image m'a fait récupérer de l'espace.

Ok, j'ai oublié de coller la taille du fichier en boucle avant et après l'opération. C'est ici.

  • Avant l'extraction de l'image.
    $ cd / var / lib / docker / devicemapper / devicemapper
    $ du -h données
    293M de données
  • Après l'extraction de l'image
    [ root @ centos7-generic devicemapper] # du -h données
    499M de données
  • Après la suppression de l'image
    [ root @ centos7-generic devicemapper] # du -h données
    293M de données

Donc, mon fichier de boucle a été réduit après la suppression de l'image. Je pense que c'est ce dont vous vous plaignez.

@stanislavb

Utilisez-vous des fichiers en boucle? Ils ne sont pas visibles dans les informations de votre docker. Je pense que vous rencontrez le même problème que lorsque le docker a commencé, la piscine était déjà là.

Pouvez-vous vérifier la taille des fichiers de sauvegarde de boucle (/ var / lib / docker / devicemapper / devicemapper / data) et vous assurer que le fichier diminue après la suppression de l'image. (du -h).

@rhvgoyal
CentOS 7, version Docker 1.6.2.el7, build 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, donc la taille du périphérique en boucle diminue en effet.

J'ai également vérifié à partir du code. Nous émettrons un rejet même si, au redémarrage, le docker trouve déjà un mince pool.

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

Conformément au code ci-dessus, les suppressions sont désactivées uniquement si l'utilisateur a transmis un périphérique de bloc de données ou un thin pool. Étant donné que nous n'avons pas réussi non plus, les rejets sont toujours actifs. C'est pourquoi cela fonctionne pour vous.

@alexDrinkwater Nous avons maintenant deux points de données corrigés dans la version 1.6. Avez-vous toujours des inquiétudes à résoudre ce problème.

CentOS 6.6

Docker version 1.5.0, build a8a31ef / 1.5.0

Avant le nettoyage de l'image

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

Vérification de la taille du fichier de données à 1929 images restantes

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

Après quelques rmi docker

[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, donc même en 1.5 ça marche.

J'ai testé cela sur une nouvelle machine.

Docker version 1.6.0, build 8aae715 / 1.6.0

Avant de tirer:

/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

après traction:

/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

supprimer l'image:

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

après suppression:

/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

Faites-moi savoir si vous avez plus de détails sur ma machine ou mes versions, etc.

@alexDrinkwater

On dirait que vous montez un périphérique séparé sur / var. Quel est le système de fichiers sur cet appareil et quelles sont les options de montage?

Pouvez-vous aussi me donner la suite.

  • table dmsetup
  • état de dmsetup
  • cat / etc / sysconfig / docker-storage

Pouvez-vous essayer le cas plus simple de garder / var à la racine avec le système de fichiers xfs. Essayer de réduire un peu le problème.

@alexDrinkwater

J'ai monté un autre disque avec une partition ext4 sur / var / lib / docker afin que les fichiers de sauvegarde en boucle soient sur ext4 (au lieu de xfs) et que les choses fonctionnent toujours pour moi.

/ dev / vdb1 sur / var / lib / docker type ext4 (rw, relatime, seclabel, data = ordonné)

Je ne sais vraiment pas ce qui est spécial dans votre configuration.

Pour être précis,

  • Avant de tirer
    / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / docker
  • Après l'extraction de l'image
    / dev / vdb1 9.8G 544M 8.7G 6% / var / lib / docker
  • Après la suppression de l'image
    / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / docker

@alexDrinkwater

L'autre différence majeure entre votre configuration et ma configuration est la version du noyau. J'utilise "3.10.0-229.el7.x86_64" alors que vous semblez utiliser "3.10.0-123.el7.x86_64". Pouvez-vous mettre à jour votre noyau et l'essayer.

Merci pour l'aide @rhvgoyal. Je ne pourrais pas mettre à jour le noyau aujourd'hui. Mais voici les paramètres que vous avez demandés:

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

Je n'ai configuré aucune option de stockage personnalisée.

Je l'ai trouvé. Je pense que cela a quelque chose à voir avec le système de fichiers ext3. Je vois aussi le problème. Essayez un autre système de fichiers, disons ext4 ou xfs et vous ne feriez pas face au problème.

/ dev / vdb1 sur / var / lib / docker type ext3 (rw, relatime, seclabel, data = ordonné)

Donc, pour une raison quelconque, si le fichier de bouclage est sur le système de fichiers ext3, cela ne fonctionne pas. Peut-être que ext3 est suffisamment ancien pour que les suppressions de boucles ne fonctionnent pas dessus.

Merci, dès que j'ai vu que le système de fichiers était ext3, j'ai pensé que ça pouvait être ça. Je suppose que si vous pouviez reproduire le problème sur ext3, nous pourrions appeler ce problème fermé. Ce sera une bonne référence pour les autres.

Pour référence, mes exemples de travail étaient Docker 1.6.2 sur le système de fichiers xfs et Docker 1.6.0 et 1.5.0 sur ext4.

@vbatts

Pouvons-nous fermer cela. La récupération d'espace fonctionne très bien sur xfs et ext4. ext3 semble trop ancien pour le supporter.

@rhvgoyal @vbatts IIRC, il y a un contrôle de compatibilité qui vérifie le système de fichiers sous-jacent. Peut-être devrions-nous ajouter un chèque de ext3 si tel est le problème ici?

Éditer:
pour référence; démon / graphdriver / overlay / overlay.go # L115

Le pilote de boucle utilise fallocate () pour percer un trou dans le fichier lorsque la suppression entre. La page de manuel Linux de fallocate () vérifie qu'elle n'est pas prise en charge sur ext3.

/ *
Tous les systèmes de fichiers ne prennent pas en charge FALLOC_FL_PUNCH_HOLE; si un système de fichiers ne prend pas en charge l'opération, une erreur est renvoyée. L'opération est prise en charge sur au moins les systèmes de fichiers suivants:
* XFS (depuis Linux 2.6.38)
* ext4 (depuis Linux 3.0)
* Btrfs (depuis Linux 3.7)
* tmpfs (depuis Linux 3.5)
* /

@thaJeztah

Si quelqu'un veut exécuter docker sur ext3, je suppose que nous devrions l'autoriser. Juste qu'ils ne recevront pas de support de suppression, la taille du fichier de boucle ne diminuera pas lorsque l'image / les conteneurs sont supprimés.

@rhvgoyal que diriez-vous de l'afficher dans docker info ? Similaire à la sortie Udev Sync Supported .

@thaJeztah

Nous avons déjà une entrée dans le docker info "Backing filesystem". Je ne sais pas pourquoi il dit extfs au lieu d'être précis sur ext2 / ext3 / ext4.

Peut être un avertissement au moment du démarrage dans les journaux devrait faire ici. Quelque chose de similaire à un avertissement concernant l'utilisation de périphériques en boucle pour un pool léger.

@thaJeztah

Et je pense que nous ne devrions le faire que si beaucoup de gens sont touchés par cela. Sinon, nous créons simplement plus de travail et de code et cela ne vaut peut-être pas la peine.

la structure syscall.Statfs_t , avec le champ Type sur ext2, ext3 et ext4 retournent tous 0xef53 , et c'est ce que nous utilisons pour détecter la magie des systèmes de fichiers.

la structure syscall.Statfs_t, avec le champ Type sur ext2, ext3 et ext4, renvoient toutes 0xef53, et c'est ce que nous utilisons pour détecter la magie du système de fichiers.

Dommage. Il aurait été bon d'avoir cette information pour faciliter l'identification des problèmes signalés.

Je suppose que nous devrions fermer ça alors?

fermeture car il s'agit d'un problème avec ext3 étant obsolète. Veuillez utiliser ext4 ou xfs

pensez-vous que cela pourrait être mieux documenté dans la documentation principale de Docker?

Que le problème soit lié au système de fichiers ou non, regardez la confusion que cela a engendrée entre deux problèmes récents.

Merci.

revenir au numéro 9786

@dbabits oui, je pense que mentionner que ext3 a des problèmes pourrait valoir la peine d'être mentionné dans la documentation. Aucune idée encore de ce que serait un endroit approprié.

Avoir un problème identique / similaire avec XFS.
Était sur le noyau "3.10.0-123.el7.x86_64", mais mis à jour maintenant sur "3.10.0-229.el7.x86_64".

Tout est supprimé (conteneur, images) mais les données contiennent toujours 100 Go.
Des idées, de l'aide?

[ root @ docker0101 ~] # ls -alh / data / docker / devicemapper / devicemapper /
total 80G
drwx ------ 2 root root 32 8 juin 16:48.
drwx ------ 5 root root 50 juin 9 07:16 ..
-rw ------- 1 racine racine 100G 16 juillet 21:33 données
-rw ------- 1 racine racine 2.0G 17 juillet 09:20 métadonnées

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

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

[ root @ docker0101 ~] # docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

[ root @ docker0101 ~] # images docker -a
RÉPERTOIRE TAG IMAGE ID CRÉÉ TAILLE VIRTUELLE

[ root @ docker0101 ~] # infos sur le docker
Conteneurs: 0
Images: 0
Pilote de stockage: devicemapper
Nom de la piscine: docker-253: 0-268599424-pool
Taille des blocs de piscine: 65,54 kB
Système de fichiers de sauvegarde: xfs
Fichier de données: / dev / loop0
Fichier de métadonnées: / dev / loop1
Espace de données utilisé: 85,61 Go
Espace de données total: 107,4 Go
Espace de données disponible: 40,91 Mo
Espace de métadonnées utilisé: 211,4 Mo
Espace de métadonnées total: 2,147 Go
Espace Métadonnées disponible: 40,91 Mo
Udev Sync pris en charge: vrai
Fichier de boucle de données: / data / docker / devicemapper / devicemapper / data
Fichier de boucle de métadonnées: / data / docker / devicemapper / devicemapper / metadata
Version de la bibliothèque: 1.02.93-RHEL7 (2015-01-28)
Pilote d'exécution: native-0.2
Version du noyau: 3.10.0-229.7.2.el7.x86_64
Système d'exploitation: CentOS Linux 7 (Core)
Processeurs: 4
Mémoire totale: 11,58 Gio
Nom: docker0101

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

[ root @ docker0101 ~] # état dmsetup
vg1-lvol0: 0 167772160 linéaire
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
Nom: docker
Version: 1.6.2
Sortie: 14.el7.centos
Architecture: x86_64
Date d'installation: ven 17 juillet 2015 09:19:54 AM CEST
Groupe: non spécifié
Taille: 33825026
Licence: ASL 2.0
Signature: RSA / SHA256, mer.24 juin 2015 05:43:12 CEST, ID de clé 24c6a8a7f4a80eb5
RPM source: docker-1.6.2-14.el7.centos.src.rpm
Date de construction: mer 24 juin 2015 03:52:32 AM CEST
Construire l'hôte: worker1.bsys.centos.org

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

[ root @ docker0101 ~] # montage
/ dev / sda5 sur / var type xfs (rw, relatime, attr2, inode64, noquota)
/ dev / mapper / vg1-lvol0 sur / type de données xfs (rw, relatime, attr2, inode64, noquota)

@tomlux Le mode de bouclage de devicemapper que vous utilisez est principalement destiné à jouer facilement avec docker. pour un travail sérieux, le bouclage sera plus lent et aura quelques limitations. Je recommande vivement de lire http://www.projectatomic.io/docs/docker-storage-recommendation/

Vous obtiendrez de meilleures performances et n'obtiendrez pas des choses comme celle-ci, en supposant que vous ayez appliqué toutes les mises à jour du système.

@tomlux

pouvez-vous ajouter "-s" à ls. Cela vous donnera des blocs réels alloués aux fichiers de données et de métadonnées. À l'heure actuelle, il montre la taille apparente des fichiers.

La sortie d'informations de docker est cependant intrigante. Il semble montrer une utilisation élevée.

ocr

@tomlux

La taille réelle des fichiers de données et de métadonnées semble donc petite. Vous pouvez utiliser "ls -alsh" pour que les tailles soient plus lisibles.

La taille du fichier de données semble donc être d'environ 79 Mo et la taille du fichier de métadonnées est d'environ 202 Ko.

Je pense que les statistiques du pool sur le nombre de blocs utilisés ne semblent pas correctes. Un redémarrage de la machine résout-il le problème?

J'ai fait un redémarrage après la mise à jour du noyau sans succès.

image

Ok, donc les fichiers de boucle sont gros et le pool pense qu'il a beaucoup de blocs utilisés. Donc, quelque chose utilise ces blocs. Pouvez-vous me donner la sortie de.

  • docker ps -a
  • images de docker
  • ls / var / lib / dokcer / devicemapper / metadata / | wc -l
  • arrêtez le docker et exécutez le suivant.
    thin_dump / var / lib / docker / devicemapper / devicemapper / metadata | grep "périphérique dev_id" | wc -l

Cela vous dira combien de périphériques légers se trouvent dans le pool.

Hmm,
maintenant nous avons des conteneurs MORTS mais pas d'images.
A déjà un redémarrage.

Semble être quelque chose de mal avec le devicemapper.
Je ne veux pas spammer ce problème.
Je peux aussi "rm -f / var / lib / docker" et reconstruire mes conteneurs. Tout est scénarisé.

image

faire "dmsetup status"

On dirait que la piscine est en mauvais état et qu'elle doit probablement être réparée.

image

Salut,

Il me semblait avoir le même problème sous Ubuntu 14.04. Cependant la cause était des volumes indésirables (cf. blog http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/). Exécuter la commande

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

libéré beaucoup d'espace disque.

Ce n'est pas résolu de manière significative. Sur une installation Ubuntu 14.04.x ​​entièrement à jour (la dernière version LTS) et avec la dernière version de Docker (installée via $ wget -qO- https://get.docker.com/ | sh ), Docker perdra continuellement de l'espace sans moyen facile de récupérer. docker stop $(docker ps -q) && docker rm $(docker ps -q -a) && docker rmi $(docker images -q) ne libère qu'une petite quantité d'espace.

Le seul moyen de récupérer tout l'espace est avec le hack suivant:

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

Ce qui nécessite ensuite de récupérer les images dont vous pourriez avoir besoin.

@bkeroackdsc cet espace pourrait-il également être lié à des volumes «orphelins»?

Je suis d'accord avec @bkeroackdsc, ce n'est pas résolu.
J'ai demandé à @rhvgoyal pourquoi il voulait tellement clore cette affaire.
à la fin, je suis tombé de docker spécifiquement à cause de ce problème.
il tue ce produit.

orphelin ou non orphelin, il n'y a pas de moyen simple et efficace de nettoyer l'espace.
il doit y avoir une option cli docker pour le nettoyage, une bonne option cli de rapport d'état et aussi une sorte de surveillance de l'espace disque car ce problème arrive à trop de personnes sur de nombreuses plates-formes.

@bkeroackdsc @sagiegurari

La raison pour laquelle je demande est que les volumes orphelins ne sont
pas lié à devicemapper.

Les volumes orphelins ne sont
pour un conteneur sont automatiquement supprimés lorsque le conteneur est supprimé.
Ce n'est _pas_ le cas (et par conception), car les volumes peuvent contenir des données
qui devrait persister après la suppression d'un conteneur.

_Pour supprimer un volume avec un conteneur_, utilisez docker rm -v [mycontainer] .
Des fonctions de gestion de volume seront ajoutées (voir https://github.com/docker/docker/pull/14242 et https://github.com/docker/docker/issues/8363),
et vous permettra de gérer les volumes «orphelins».

Une taille croissante de /var/lib/docker ne doit pas être une indication
ce devicemapper perd des données, car la taille de ce répertoire augmente
peut également être le résultat de volumes (orphelins) qui n'ont pas été nettoyés
par l'utilisateur (le docker stocke toutes ses données dans ce chemin).

J'espère vraiment que ces 2 éléments donneront les capacités nécessaires.
J'ai bien compris le deuxième élément, mais le premier (# 14242) n'explique pas en haut de quoi il s'agit à part que c'est une api de volume (ce qui signifie, je ne sais pas quelles capacités il donne).

@sagiegurari cela fait partie des exigences pour implémenter la gestion du volume d'

@swachter Merci d'avoir publié cette solution de contournement, j'ai récupéré 6 Go avec l'image ci-dessus.

nous avons corrigé le problème de volume de fuite avec un hack sale, car il empêchait le démon docker de démarrer avant que le service n'expire sur nos hôtes docker à taux de désabonnement élevé:

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

qui résout le problème sans vider les images pré-mises en cache.

Pouvons-nous discuter de la question des volumes qui fuient dans un autre numéro. En discuter ici donne l'impression qu'il s'agit d'un problème de mappage de périphériques alors qu'il ne l'est pas.

@tomlux @rhvgoyal

Êtes-vous déjà parvenu à une conclusion sur ce qui se passe dans la boîte CentOS 7? Mon hôte docker est presque identique et je rencontrais le même problème. J'ai suivi jusqu'au point où @rhvgoyal a demandé d'exécuter la commande thin_dump . Après, je suis allé démarrer le démon docker et il ne démarre pas. Je viens de supprimer / var / lib / docker et de redémarrer depuis, mais je voulais juste savoir si une résolution a été trouvée car je (ainsi que d'autres) pourrais la rencontrer à nouveau.

[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

J'ai trouvé la source de mon problème. Malgré son apparence, cela n'avait aucun rapport avec les problèmes du fil de discussion. Cela vient juste d'un malentendu sur le fonctionnement de docker. Tous, les conteneurs morts tenaient toujours l'espace disque qu'ils avaient alloué lors de leur exécution. J'ai juste dû retirer toutes les carcasses de conteneurs pour libérer de l'espace disque. Je me souviens de cela dans ce fil, mais je pensais que seuls les volumes montés étaient considérés, pas l'espace disque alloué par le conteneur.

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

@tomlux Cela peut aussi avoir été votre problème puisque votre sortie de docker ps -a montrait plusieurs conteneurs Dead .

docker rm ne libère pas l'espace disque du conteneur

boot2docker récent dans OS X VirtualBox. OS X entièrement patché.

Je construis un gros conteneur (47 Go) et il a un problème indiquant que je devrais reconstruire le conteneur. J'ai donc arrêté le conteneur et ai fait docker rm. Double-vérification à l'aide de docker ssh'df -h', je trouve que l'utilisation du disque est toujours de 47 Go. Le conteneur a 75 Go.

Je vais donc devoir à nouveau tuer la VM docker.

Pouvons-nous y arriver?

@ awolfe-silversky est-ce que l'espace disque _à l'intérieur_ de la VM est renvoyé? Si c'est en dehors de la VM, cela peut être sans rapport.

@ awolfe-silversky aussi; avez-vous également supprimé _image_? supprimer uniquement le conteneur peut ne pas aider beaucoup si l'image est toujours là

@ awolfe-silversky ce problème concerne devicemapper - et si vous utilisez docker-machine / boot2docker, vous êtes beaucoup plus susceptible d'exécuter aufs . Je me demande aussi si vous avez docker rmi 'votre grande image.

cela vaut la peine de lancer docker images , et docker info pour voir si les choses sont vraiment aussi désastreuses que vous le faites paraître :)

(oui, si vous avez toujours le vm et que l'image est supprimée, nous devrions ouvrir un nouveau problème et déboguer davantage, car vous avez trouvé un cas de coin étrange)

Je n'ai pas supprimé l'image. Il provient d'un registre docker interne.
J'ai utilisé un script awk pour dimensionner les images - au total 6,9 Go.

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

C'est sale mais je sais que toutes les tailles d'image sont en Mo.

Voici comment j'essayais de diagnostiquer l'utilisation:

 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

En ce moment, j'ai une boîte avec 0 images.
docker volume ls -qf dangling=true ne montre rien.
docker volume ls montre beaucoup de volumes, qui sont, par définition, orphelins, car il n'y a pas d'images pour les posséder.
docker volume rm $(docker volume ls) affiche de nombreux messages de ce type:

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

Le répertoire du mappeur de périphériques consomme 30 Gio.
Docker version 1.10.2, build 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)

Aussi, pourquoi l'installation par défaut utilise-t-elle l'option de stockage «fortement déconseillée»?
Pourquoi ne l'ai-je pas dit lors de l'installation?

J'ai exactement le même problème ici sur une instance 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

Sur les instances où j'installe régulièrement de nouvelles images docker, la seule solution est de faire ce qui suit:

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

Je ne pense pas vraiment qu'une telle chose soit acceptable dans un environnement de production

quelques infos supplémentaires:

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

Comme ce bogue existe depuis des années et qu'il semble qu'il n'est pas encore clos, pourriez-vous mettre dans la documentation de docker sur devidemapper comment détruire toutes les informations de docker en toute sécurité?
je veux dire, dans cette page: https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
mettre quelque chose comme "mappeur de périphérique de nettoyage" et comment le faire.

J'essaierai de faire rm -rf / var / lib / docker mais je ne me sens pas à l'aise de faire ça. Quelqu'un peut-il me dire si c'est sûr?

J'utilise gentoo linux dans mon ordinateur portable quotidien et j'ai essayé docker pour apprendre mais remplir mon disque et réinstaller tout le système n'est pas une option car ce n'est pas une VM et réinstaller gentoo prend du temps.

Merci pour votre travail.

@mercuriete Sur votre machine de développement, désinstallez simplement docker, supprimez le répertoire et réinstallez-le. Fonctionne très bien.

@ ir-fuel: Je viens de faire ça et maintenant j'ai ceci:

$ 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

J'utilise service docker start

@ ir-fuel merci, ça marche bien. : +1:

Réinstaller docker pour libérer de l'espace disque est la réponse la plus ridicule que j'ai rencontrée en cherchant une solution à ce problème. Non seulement c'est une perte de temps, mais ce n'est même pas autorisé dans la plupart des environnements. C'est un bon moyen d'être payé si vous travaillez à l'heure.

Je suis complètement d'accord. Il est étonnant qu'un produit comme Docker continue de consommer de l'espace disque sans que vous ne puissiez rien y faire, sauf pour désinstaller / réinstaller.

S'enregistrer une autre fois pour ce problème pour voir que rien n'a changé. +1

Ce problème est marqué comme clos. Nous avons besoin d'une résolution. Aucune solution de contournement, aucune reconfiguration. Quel est le statut réel et quels sont les paramètres de configuration impliqués? Supprimer et recréer un nœud Docker de production n'est pas acceptable.

Et quelle est l'alternative? Comment pouvons-nous éviter cela?

Si cette fonctionnalité n'est pas recommandée à utiliser - pourquoi est-elle silencieuse et par défaut
une? Si vous ne vous souciez pas des personnes qui utilisent devicemapper - je pourrais même être d'accord
avec ça. Mais informez-en l'utilisateur! Réalisez-vous la quantité de
les gens ont mal à la tête en raison de cette étonnante «solution de contournement» sur laquelle vous vous êtes arrêté ??
Le 23 juin 2016 à 16 h 32, "kpande" [email protected] a écrit:

la solution de contournement consiste à éviter d'utiliser le pilote de mappeur de périphérique docker,
malheureusement.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397, ou muet
le fil
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Il y a toujours rkt

le snark général de garce inutile est sans aucun doute pourquoi personne en amont ne se soucie de vous donner des réponses appropriées.

personne ne vous a forcé à utiliser Docker.

C'est comme Oracle disant à un développeur Java d'utiliser PHP en raison d'un bogue JVM. Ce n'est pas non plus cohérent avec le pitch de l'ascenseur ici

Il y a trois ans, Docker a rendu simple et accessible à tous une technologie de noyau Linux ésotérique appelée conteneurisation.

Je suis sûr que beaucoup de gens sont reconnaissants que Docker ait décollé comme il l'a fait et que cela n'aurait pas pu se produire sans le bénévolat de la communauté. Cependant, il ne devrait pas être si difficile d'admettre qu'il a aussi ses problèmes sans abandonner implicitement la ligne «Je suis un contributeur en amont, alors tais-toi et écoute» chaque fois que quelqu'un soulève un point qui ne lui plaît pas.

Attendez. J'ai signalé un problème, fourni les détails de ma machine et de sa configuration,
ce que je ne suis pas obligé de faire. Aucune équipe de développement n'a répondu à mon bug et à d'autres
rapports dans une période de six mois. Maintenant j'ai déclaré ce fait, vous appelez mon comportement
vache? Êtes-vous même open-source? Je recherche un projet Go sur lequel travailler, et
ce ne sera pas Docker, je vous le donne. Est-ce votre objectif?
Le 23 juin 2016 à 16h45, "gregory gray" [email protected] a écrit:

Si cette fonctionnalité n'est pas recommandée à utiliser - pourquoi est-elle silencieuse et par défaut
une? Si vous ne vous souciez pas des personnes qui utilisent devicemapper - je pourrais même être d'accord
avec ça. Mais informez-en l'utilisateur! Réalisez-vous la quantité de
les gens ont mal à la tête en raison de cette étonnante «solution de contournement» sur laquelle vous vous êtes arrêté ??
Le 23 juin 2016 à 16 h 32, "kpande" [email protected] a écrit:

la solution de contournement consiste à éviter d'utiliser le pilote de mappeur de périphérique docker,
malheureusement.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397,
ou couper le fil
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Tout d'abord, si vous rencontrez toujours ce problème, veuillez ouvrir un nouveau numéro;

Attendez. J'ai signalé un problème

Vous avez répondu sur un problème fermé datant de 3 ans; suite à la discussion ci-dessus, le problème initial a été résolu. Votre problème _peut_ être le même, mais nécessite plus de recherche pour être sûr; les erreurs que vous rapportez indiquent qu'il s'agit peut-être d'autre chose.

Je recommande vraiment d'ouvrir un nouveau problème, sans commenter un problème fermé

fourni les détails de ma machine et de sa configuration, ce que je ne suis pas obligé de faire.

Vous n'êtes pas obligé de le faire, mais sans aucune information, il est peu probable que cela soit résolu. Ainsi, lorsque vous signalez un bogue, veuillez inclure les informations demandées dans le modèle:
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

Aucun membre de l'équipe de développement n'a répondu à mes rapports de bogues et à d'autres en six mois.

Si vous voulez dire "l'un des responsables de la maintenance", gardez à l'esprit qu'il y a près de 24 000 problèmes et PR, et moins de 20 responsables , dont beaucoup font cela en plus de leur travail quotidien. Tous les commentaires ne seront pas remarqués, surtout s'il s'agit d'un problème clos.

Si cette fonctionnalité n'est pas recommandée, pourquoi est-elle silencieuse et par défaut?

C'est la valeur par défaut si _aufs_, _btrfs_ et _zfs_ ne sont pas pris en charge, vous pouvez trouver la priorité utilisée lors de la sélection des pilotes; voir daemon / graphdriver / driver_linux.go . Il est toujours au-dessus de la superposition, car malheureusement, il reste des problèmes avec ce pilote qui peuvent affecter certaines personnes.

La sélection automatique d'un pilote graphique est juste pour "faire fonctionner les choses"; le meilleur pilote pour _votre_ situation dépend de _votre_ cas d'utilisation. Docker ne peut pas prendre cette décision automatiquement, c'est donc à l'utilisateur de la configurer.

Si vous ne vous souciez pas des personnes qui utilisent devicemapper, cela pourrait même me convenir.

En relisant la discussion ci-dessus, je vois que les mainteneurs de devicemapper en amont se sont penchés sur cette _plusieurs fois_, essayant d'aider les utilisateurs à signaler ces problèmes et à résoudre le problème. Le problème a été résolu pour ceux qui l'ont signalé, ou dans certains cas, dépendait des distributions mettant à jour les versions de devicemapper. Je ne pense pas que cela puisse être considéré comme «insouciant».

Aussi, pourquoi l'installation par défaut utilise-t-elle l'option de stockage «fortement déconseillée»?

L'exécution sur des périphériques en boucle est très bien pour faire fonctionner docker, et actuellement le seul moyen de configurer automatiquement devicemapper. Pour la production, et pour obtenir de meilleures performances globales, utilisez direct-lvm, comme expliqué dans la section devicemapper du guide de l'utilisateur du pilote de stockage.

Pourquoi ne l'ai-je pas dit lors de l'installation?

C'est vraiment hors de portée de l'installation. Si vous comptez utiliser un logiciel en production, il devrait être raisonnable de supposer que vous vous familiarisez avec ce logiciel et que vous savez ce qui est nécessaire pour le configurer pour votre cas d'utilisation. Certains responsables ont même fait valoir si l'avertissement devait être émis. Linux n'est pas un système d'exploitation "main dans la main" (votre distribution affiche-t-elle un avertissement indiquant qu'une perte de données peut se produire si vous utilisez RAID-0? Si vous avez des ports ouverts dans votre pare-feu?)

Profondément réticent comme je le suis, à ressusciter à nouveau ce fil ancien, il n'y a toujours pas de conseils significatifs sur la façon de contourner ce problème sur une machine existante rencontrant ce problème.

C'est mon meilleur effort à un tldr; pour le fil entier; J'espère que cela aidera les autres à trouver ce fil.

Problème rencontré

Votre volume a une quantité d'espace significative (et croissante) qui est en /var/lib/docker et vous utilisez ext3.

Résolution

Vous n'avez pas de chance. Mettez à niveau votre système de fichiers ou voyez blowing docker away en bas.

Problème rencontré

Votre volume a une quantité d'espace significative (et croissante) qui est en /var/lib/docker et vous _pas_ utilisez ext3 (par exemple, système utilisant actuellement xfs ou ext4)

Résolution

Vous pourrez peut-être récupérer de l'espace sur votre appareil à l'aide des commandes docker standard.

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

Exécutez ces commandes:

docker volume ls
docker ps
docker images

Si vous n'avez rien répertorié dans l'un de ceux-ci, voir blowing docker away en bas.

Si vous voyez d'anciennes images obsolètes, des conteneurs inutilisés, etc., vous pouvez effectuer un nettoyage manuel avec:

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

Cela devrait récupérer une grande partie de l'espace du conteneur caché dans le devicemapper.

Souffler docker

Cela n'a pas fonctionné? Vous n'avez pas de chance.

Votre meilleur pari à ce stade est:

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

Cela détruira toutes vos images de docker. Assurez-vous d'exporter celles que vous souhaitez conserver _avant_ de le faire.

En fin de compte, veuillez lire https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-production; mais j'espère que cela aidera les autres qui trouveront ce fil.

Si vous rencontrez des problèmes lors de l'utilisation des conseils ci-dessus, ouvrez un nouveau ticket qui résout spécifiquement le problème que vous rencontrez et établissez un lien vers ce problème; ne le postez pas ici.

rm -rf / var / lib / docker

Vous pouvez également utiliser nuke-graph-directory.sh .

Après avoir supprimé les fichiers comme indiqué ci-dessus, je ne peux plus démarrer Docker:
Mar 02 04:53:40 pmdc001b dockerd [29522]: Erreur au démarrage du démon: erreur lors de l'initialisation du pilote graphique: open / var / lib / docker / devicemapper / devicemapper / data: aucun fichier ou répertoire de ce type

Je viens de rencontrer ce problème sur CentOS 7.3 et je ne voulais pas déboguer les problèmes de devmapper qui existent depuis plus de 3 ans, j'ai donc suivi ce guide DC / OS, purgé les packages d'origine, basculé vers overlayfs et tout semble bien fonctionner maintenant : https://dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/ (a dû modifier la commande ExecStart pour la version 17.03 de docker -> "dockerd --storage-driver = superposition ")

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

(la purge des volumes, des images et des conteneurs n'a pas aidé. La suppression d'éléments dans / var / lib / docker a conduit au problème décrit par @ gdring2 )

Lancer docker system prune libéré beaucoup d'espace sur mes machines.

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

Eh bien, c'est un peu ... nul.

Dans mon cas, j'ai trouvé ce problème après avoir désinstallé Docker et supprimé le répertoire /var/lib/docker , donc je n'ai pas pu exécuter l'équivalent de service docker stop ... service docker start .

J'ai trouvé que mon système ne signalait pas l'espace de suppression de /var/lib/docker comme libéré (j'avais ~ 14 Go assis dans ce qui semblait être des limbes).

La solution à ce problème consiste simplement à recharger votre système de fichiers, dans mon cas, je viens de redémarrer et l'espace a été récupéré.

Je ne peux pas croire que ce soit toujours un problème! allez les gars, j'ai toujours ça

@ shahaf600 quelle version de docker utilisez-vous? Voir aussi mon commentaire ci-dessus; https://github.com/moby/moby/issues/3182#issuecomment -228298975

Sans détails, il n'y a pas grand chose à dire sur votre situation; votre cas pourrait être causé par un problème différent, mais aboutissant à un résultat similaire.

bien

après avoir acheté un de ces déchets et vu l'état du support, je l'ai retourné.

Il y a votre premier problème @misterbigstuff ... vous avez acheté quelque chose qui est open source?

et l'a retourné

Cette page vous a été utile?
0 / 5 - 0 notes