Moby: Device-Mapper gibt keinen freien Speicherplatz für entfernte Bilder frei

Erstellt am 12. Dez. 2013  ·  206Kommentare  ·  Quelle: moby/moby

Docker behauptet, über docker info Speicherplatz freigegeben zu haben, nachdem ein Bild gelöscht wurde, aber die Datendatei behält ihre frühere Größe bei, und die für die Backend-Datei des Geräte-Mapper-Speichers zugewiesene Datei mit geringer Dichte wächst weiter, ohne an weitere Ausdehnungen gebunden zu sein zugewiesen werden.

Ich benutze lxc-docker unter 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

Diese Befehlsfolge zeigt das Problem:

Bei einer docker pull stackbrew/ubuntu:13.10 erhöhten Speicherplatznutzung wurden docker info gemeldet, bevor:

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

Und nach 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

Und nach docker rmi 8f71d74c8cfc wird Folgendes zurückgegeben:

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

Das einzige Problem ist, dass die Datendatei auf 414 MB (849016 512-Byte-Sektorblöcke) pro stat . Ein Teil dieses Speicherplatzes wird nach dem Löschen eines Bildes ordnungsgemäß wiederverwendet, die Datendatei wird jedoch nie verkleinert. Und unter mysteriösen Bedingungen (die noch nicht reproduzierbar sind) habe ich 291,5 MiB zugewiesen, die nicht einmal wiederverwendet werden können.

Mein dmsetup ls sieht so aus, wenn 0 Images installiert sind:

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

Und ein du der Datendatei zeigt dies:

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

Wie kann Docker Speicherplatz zurückfordern und warum macht Docker dies nicht automatisch, wenn Bilder entfernt werden?

arestoragdevicemapper exexpert kinbug

Hilfreichster Kommentar

Ich zögere zutiefst, diesen alten Faden wiederzubeleben, aber es gibt immer noch keinen aussagekräftigen Rat, wie man dieses Problem auf einer vorhandenen Maschine umgeht, auf die dieses Problem stößt.

Dies ist meine größte Anstrengung bei einem tldr; für den gesamten Thread; Ich hoffe es hilft anderen, die diesen Thread finden.

Problem aufgetreten

Ihr Volume verfügt über eine erhebliche (und wachsende) Menge an Speicherplatz in /var/lib/docker und Sie verwenden ext3.

Auflösung

Du hast kein Glück mehr. Aktualisieren Sie Ihr Dateisystem oder sehen Sie unten blowing docker away .

Problem aufgetreten

Ihr Volume verfügt über eine erhebliche (und wachsende) Menge an Speicherplatz in /var/lib/docker und Sie verwenden ext3 nicht (z. B. System, das derzeit xfs oder ext4 verwendet).

Auflösung

Möglicherweise können Sie mithilfe von Standard-Docker-Befehlen Speicherplatz auf Ihrem Gerät zurückfordern.

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

Führen Sie die folgenden Befehle aus:

docker volume ls
docker ps
docker images

Wenn in keinem dieser Elemente etwas aufgeführt ist, sehen Sie unten blowing docker away .

Wenn Sie alte veraltete Bilder, nicht verwendete Container usw. sehen, können Sie eine manuelle Bereinigung durchführen mit:

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

Dies sollte einen Großteil des verborgenen Containerplatzes im Devicemapper zurückgewinnen.

Docker wegblasen

Hat nicht funktioniert? Du hast kein Glück mehr.

Ihre beste Wette zu diesem Zeitpunkt ist:

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

Dadurch werden alle Docker-Bilder zerstört. Stellen Sie sicher, dass Sie diejenigen exportieren, die Sie vor diesem Vorgang beibehalten möchten.

Lesen Sie letztendlich https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-Production. aber ich hoffe, dass dies anderen helfen wird, die diesen Thread finden.

Wenn Sie Probleme mit der Verwendung der oben genannten Ratschläge haben, öffnen Sie ein neues Ticket , das sich speziell mit dem aufgetretenen Problem befasst, und verknüpfen Sie es mit diesem Problem. poste es nicht hier.

Alle 206 Kommentare

+1, ich bin sehr daran interessiert, eine Diskussion zu diesem Thema zu hören. Meine bisherige Strategie war

  • Sei vorsichtig, was du baust / ziehst
  • Seien Sie bereit, Ihr / var / lib / docker wegzublasen: neutral_face:

@ AaronFriel , auf welcher Version von Docker bist du? 0,7,1?

/ cc @regilero (Link auch zu # 2276)

Ausgehend von einem frischen / 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

Dann, nachdem Docker Busybox gezogen hatte, wuchs es ein bisschen:

# 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 vergrößert die Datei zwar nicht, macht aber den Speicherplatz im Devicemapper-Pool frei:

# 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

Die Loopback-Datei wächst nicht, wenn wir das Bild erneut herunterladen:

# 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

Es scheint also, dass wir die Loopback-Datei nicht erneut sparsifizieren können, wenn das Thinp-Gerät einen Block verwirft.

Wenn ich jedoch eine Datei innerhalb des Container-Fs-Bildes erstelle, wird der Speicherplatz in der Loopback-Datei zurückgefordert.
Dh ich habe das im Busybox-Bild gemacht:

 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

Dadurch wurde die Datendatei von 299 Millionen auf 344 Millionen erhöht. Aber als ich a_file.bin entfernte (und ein bisschen wartete), wurde es wieder 299M.

Das scheint mir also ein Devicemapper-Fehler zu sein. Das heißt, es leitet Rückwürfe vom Thinp-Gerät an das zugrunde liegende Gerät weiter, aber es wird nicht verworfen, wenn Thinp-Geräte aus dem Pool entfernt werden.

Dies scheint ein Kernel-Problem zu sein. Ich habe versucht, es mit BLKDISCARD zu umgehen, aber ich bin gescheitert. In diesen Fehlern finden Sie einige Details: https://bugzilla.redhat.com/show_bug.cgi?id=1043527

Ich habe meine Problemumgehung in https://github.com/alexlarsson/docker/tree/blkdiscard angegeben , aber wir untersuchen immer noch, ob wir es besser machen können.

Dieses Problem tritt auch unter CentOS (2.6.32-358.23.2.el6.x86_64) mit Docker 0.7.0 auf. Alt, aber das Problem ist nicht auf Ubuntu beschränkt.

Gleiches Problem unter Arch GNU / Linux 3.12.6-1-ARCH, Docker Version 0.7.2.

Existiert noch auf 0.7.0 unter CentOS.

Existiert noch in 0.7.2 auf Ubuntu 12.04.3 LTS.

Ein Großteil des Platzes befindet sich in docker/devicemapper/devicemapper/data und metadata , aber auch in docker/devicemapper/mnt

Es ist schön, dass ich erfahren habe, dass Sie die Container-Dateisysteme in docker/devicemapper/mnt/SOME_KIND_OF_ID/rootfs

aber es ist nicht ordentlich, dass meine Festplatte fast vollständig aufgebraucht ist und nur durch rmdir -r docker repariert werden kann.

Ich habe ein ähnliches Problem beim Schreiben der Docker-Unterstützung für rspec-system. Meine Test-VM (Docker-Host) verfügt über ein 8-GB-Laufwerk. Nachdem ich wiederholt Images erstellt habe, ohne sie zu löschen, füllt sich mein Laufwerk. Nach dem Entfernen aller Bilder und Container ist das Laufwerk jedoch immer noch zu 100% voll. Ich dachte, es sei ein ID-10T-Fehler, gab aber einfach auf und zerstörte die VM insgesamt.

Gibt es noch in 0.7.5 auf Ubuntu 13.04.

Dieses Problem wurde durch PR # 3256 behoben, das kürzlich zusammengeführt wurde. Dieses Update wird in einer zukünftigen Version enthalten sein.

Ich schließe dieses Problem jetzt, weil das Update zum Master zusammengeführt wurde.

Hinweis: Es wird nicht vollständig behoben, bis Sie auch einen Kernel mit http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= ausführen

Was ist die Lösung, um Platz zu entfernen. Ich benutze Rhel 6.5 und es kann eine Weile dauern, bis ich den neuen Kernel bekomme.

von meinem Iphone gesendet

Am 21. Januar 2014 um 6:18 Uhr schrieb Alexander Larsson [email protected] :

Hinweis: Es ist erst vollständig behoben, wenn Sie auch einen Kernel mit http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= ausführen

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an.

@logicminds Es gibt keine super einfache Möglichkeit, den Raum atm wiederherzustellen. Technisch sollte es möglich sein, die Loopback-Dateien manuell neu zu sparsifizieren. Dies würde jedoch erfordern, dass alle nicht verwendeten Blöcke auf Null gesetzt werden oder etwas, um die spärlichen Bereiche leicht erkennen zu können, was beim Entfernen von Thinp-Geräten nicht der Fall ist.

@alexlarsson Betrifft dies auch OEL 6.5? Das OEL 6.5 verwendet tatsächlich den Linux-Kernel uek 3.8, und da ich die Option habe, von einem Kernel von 2.6 auf 3.8 zu wechseln, könnte dies für mich ein einfacher Wechsel sein.

@logicminds Ich weiß noch nicht einmal, ob sich dieses Commit im Upstream-Kernel befindet. Dieser Link stammt aus dem Device-Mapper-Baum. Es ist definitiv nicht in 3.8.

Ich möchte ein Tool wie fstrim erstellen, mit dem der Speicherplatz wiederhergestellt werden kann.

@alexlarsson Problem https://bugzilla.redhat.com/show_bug.cgi?id=1043527 wurde offiziell wegen "unzureichender Daten" geschlossen. Bedeutet das, dass der Patch es nicht in den Kernel schafft? Wird es noch benötigt?

@vrvolle Der Patch, der die vom Docker verwendete

Ich habe immer noch dieses Problem mit Docker 0.9 auf Centos 6.5 mit dem Standardkernel 2.6.32.

Ich bin mir nicht sicher, was Sie zuvor über dieses Commit in Device-Mapper gesagt haben. Können Sie bestätigen, dass dieser Fehler behoben werden sollte, wenn ich meinen Kernel auf 3.8 migriere?

Danke im Voraus.

@ nicolas-van Nein, Sie benötigen dieses Commit: https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316

Es ist in 3.14 und kann in verschiedenen 3.xy-Backports sein

Ich habe vor einiger Zeit Docker installiert, um ein Image zu erstellen und es in einem Container auszuführen. Einige Zeit später löschte ich alle Bilder und Container, einschließlich der Docker-Anwendung und des Hauptordners.
Jetzt ist mir klar, dass von insgesamt 4 GB / 24 GB frei / verwendet (df -h) der Befehl du / -sh nur 10 GB meldet, sodass weitere 10 GB nicht berücksichtigt werden. Das ist mehr weniger als die Größe der mit Docker generierten temporären Bilder, könnte dies mit diesem Fehler zusammenhängen. Ich habe Centos 6.5 und Docker 0.9 verwendet.

Ich habe Docker mit yum und Entwickler aus / dev / mapper / docker * mit dmsetup sowie rm / var / lib / docker -Rf entfernt, und trotzdem werden die Datenträgerberichte mit df 10 GB verwendet, die ich nirgendwo finden kann.

@Jacq Möglicherweise wird eine Datei noch von einem Prozess am Leben erhalten, für den ein Dateideskriptor geöffnet ist. Hast du neu gestartet? Das würde sicherstellen, dass das nicht passiert.

Ich verwende Linux 3.14.4-1-ARCH und Docker 0.11.1 entfernte alle Images und Container.
und die Datei / var / lib / docker / devicemapper / devicemapper blieb nur hängen und verbrauchte ungefähr 1,5 GB

Hier ist die Ausgabe von, nachdem ich mit ein paar Mongodb-Sachen herumgespielt habe. Ich denke, die Dateigröße muss spärlich zugewiesen werden, da mein / var nicht einmal so groß ist.

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

Entschuldigung, ist der Fehler jetzt behoben? Ich habe es in Gentoo erlebt.

@bolasblack Ich laufe Gentoo und bin auf dieses Problem

Ich verwende die neuesten Gentoo-Quellen, die 3.14.14 für x86_64 sind. Ich habe mir https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316?diff angesehen und dieser Patch wird auf meine Quellen angewendet. Ich habe Docker Docker Version 1.1.0, Build 79812e3.

@alexlarsson Vielen Dank, dass Sie nach so langer Zeit wieder auf dieses geschlossene Problem aufmerksam gemacht haben. Es scheint, als würde es immer noch Ärger verursachen. Irgendein Wort zum Status von # 4202?

Dies ist immer noch ein Problem! Ich denke, ich werde vorerst wieder AUFS verwenden.

@daniellockard AUFS scheint inoffiziell veraltet zu sein: # 783 und # 4704, also viel Glück damit.

Huch ... wo sind diese 25 GB geblieben? Oh, in diese eine Datei ... Ich verwende Kernel 3.16.2 f20 64b

Der Link zur 'Problemumgehung' ist unterbrochen ... was ist das? und unterstützt mein Kernel es ... wenn Torvalds in 3.14 begangen hat, vermute ich, dass Fedora es in 3.16 sehen sollte, nein?

+1

+1

+1

+1 scheint immer noch auf Ubuntu Trusty, 3.13.0-36-generic mit Docker Version 1.3.1, Build 4e9bbfa, zu laufen

+1 auch auf Trusty. Lohnt es sich, 14.10 zu überprüfen, das 3.16 verwendet?

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

Die Top-Committer markieren, weil das lächerlich ist. Es muss ein öffentliches Gespräch darüber stattfinden und das Docker-Team muss zugeben, dass dieser Fehler zu Containern oder Systemen führen kann, die regelmäßig kaputt gehen und neu erstellt werden müssen. Ich kenne bereits mehrere Leute, die verrückte Devops-Lösungen implementieren mussten, wie z. B. das regelmäßige Reimaging ihrer Docker-Hosts jede oder jede zweite Woche, weil ihre Build-Bots so viel Abwanderung haben. Ich habe dieses Problem vor fast einem Jahr eingeführt und es wurde, soweit ich das beurteilen kann, keine endgültige Lösung erstellt, und ältere Kernel, die angeblich unterstützt werden, sind es nicht.

Docker-Team: Bitte recherchieren Sie, um festzustellen, welche Kernelversionen betroffen sind, warum und mit welchem ​​Patch das Problem behoben wird, und dokumentieren Sie es. Veröffentlichen Sie diese Informationen zusammen mit den von Ihnen unterstützten Kernelversionen, da Docker-Kunden derzeit immer wieder von diesem Problem betroffen sind. Dies zeigt sich daran, dass ich immer noch jede oder jede zweite Woche E-Mails zu diesem Problem erhalte. Im Ernst, dies ist ein aktuelles Problem und seit vor 1.0 ein Schmerzpunkt.

Aus meiner Sicht gibt es mehrere Möglichkeiten, dieses Problem auf zufriedenstellende Weise zu beheben, um die E-Mails zu stoppen, die ich für +1 zu diesem Problem erhalte:

  1. Benachrichtigen Sie Benutzer, wenn Device-Mapper auf einem nicht unterstützten Kernel verwendet wird, und geben Sie ihnen detaillierte Anweisungen zum Zurückfordern von Speicherplatz. Richten Sie in Docker nach Möglichkeit automatisch einen entsprechenden Prozess ein. Ich würde empfehlen, dass dieser Hinweis auch ausgegeben wird, wenn die Docker-CLI für einen Host verwendet wird, der unter diesem Problem leidet, damit Benutzer bei der Remoteverwaltung von Hosts über die Docker-CLI darauf hingewiesen werden, dass einige Hosts möglicherweise nicht ordnungsgemäß Speicherplatz zurückfordern.
  2. Beheben Sie das Problem (irgendwie). Ich weiß nicht genug über die Kernel-Entwicklung, um zu wissen, was dies bedeuten würde, aber basierend auf meiner Anfängerlesung schlage ich Folgendes vor:

ein. Da Device Mapper ein Kernelmodul ist, bringen Sie eine funktionierende, funktionierende Version davon als dm-docker in den Docker-Quellbaum

b. Nehmen Sie ausreichend Änderungen an dm-docker , damit es mit dem Geräte-Mapper koexistieren kann.

c. Installieren Sie auf betroffenen Plattformen das dm-docker-Kernelmodul bei der Installation und verwenden Sie standardmäßig dm-docker .

  1. Ändern Sie Ihre Installationsdokumente und die Website docker.com so, dass sie eine Warnung zu betroffenen Kernelversionen enthalten, und fügen Sie den Paketen eine Laufzeitprüfung hinzu, um den korrekten Device-Mapper-Vorgang zu überprüfen, und melden Sie sie gegebenenfalls dem Benutzer.

Dies sollte ein blockierendes Problem für die nächste stabile Version von Docker sein, da es einfach inakzeptabel ist, weiter daran zu arbeiten und die Benutzer im Stich zu lassen.

Persönlich sehe ich das CoreOS als die einzige stabile Linux-Distribution für Docker (bis dieses Problem behoben ist).

Docker-Team: Ich weiß, dass dieses Problem nicht durch Ihre Komponente verursacht wird, aber bitte helfen Sie uns, Ihre Software auch auf der anderen Linux-Distribution zu verwenden. Es wäre in Ordnung, wenn Sie dieses Problem auch als bekannte Einschränkung von Docker in der Dokumentation erwähnen könnten, damit andere Personen ihre Zeit nicht verschwenden.

Vielen Dank!
Martin

+1 etwas muss getan werden.

Es wäre schön, wenn für dieses Problem etwas offensichtlicher wäre, als sich in die (geschlossene) Liste der Github-Probleme vertiefen zu müssen. Es hat lange gedauert, um tatsächlich festzustellen, dass dies das zugrunde liegende Problem war, und es wäre schön gewesen, einen Einblick in dieses Problem zu bekommen.

Wir vorgelagerten Device Mapper-Entwickler (ich und Joe Thornber) hatten absolut das Bewusstsein, dass dieses Problem immer noch ein Problem für die Menschen ist. Wir haben das Problem sofort behoben, als wir darauf aufmerksam gemacht wurden (von @alexlarsson im Dezember 2013) und es für die Aufnahme in alle stabilen Kernel zu diesem Zeitpunkt markiert haben, siehe: http://git.kernel.org/linus/19fa1a6756ed9e9 ( "dm thin: Verwerfungsunterstützung für einen zuvor freigegebenen Block korrigieren")

Joe Thornber wurde gerade darauf aufmerksam gemacht, dass @alexlarsson Trim-Pool im Docker-Go-Code implementiert hat. Als ich ihn darauf hinwies, übernahm er die Implementierung eines eigenständigen 'thin_trim'-Tools, das als Teil des' Device-Mapper-Persistent-Data'-Pakets (zumindest unter Fedora, CentOS, RHEL) verteilt wird. Siehe:
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

Also ... alles in allem müssen Benutzer, die Kernel ohne Upstream-Commit ausführen, dies beheben, indem sie Kernel ausführen, die besser unterstützt werden. Ich kann einfach eine Notiz an [email protected] senden, um den Fix auf alle stabilen Kernel zu übertragen, die ihn jedoch nicht haben. Bitte lassen Sie mich wissen, welche stabilen Kernel diese Korrektur nicht haben.

In Zukunft möchten wir, dass Docker regelmäßig 'thin_trim' für das von Docker verwendete Thin-Pool-Gerät ausführt. Aber wir werden diese Brücke überqueren, sobald 'thin_trim' in den Distributionen weit verbreitet ist.

@shabbychef @daniellockard nein, AUFs sind nicht veraltet - zuerst ist nur eines dieser Probleme geschlossen, und wenn ich weiter lese , schätze ich, dass https://github.com/docker/docker/issues/783#issuecomment -38731137 ist lesenswert:

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 Könnten Sie hack/check_config.sh etwas hinzufügen, um Benutzern mitzuteilen, dass ihr Kernel diesen Patch nicht hat?

@SvenDowideit leider ist die fragliche Änderung nicht in einem beliebigen Kernel identifiziert. Für den Anfang hat Commit 19fa1a6756ed9e9 die Version der Thin- oder Thin-Pool-Ziele nicht gestoßen. Aber selbst wenn dies der Fall wäre, würde diese Version über alle stabilen Kernel hinweg variieren (und deshalb sind Versionsfehler innerhalb eines "stabilen" Commits schlecht. Dies ist ein Grund für die manuelle Bearbeitung aller Kernel, auf die das Commit zurückportiert wird).

ABER Benutzer mit einer Thin- und Thin-Pool-Zielversion> = 1.12.0 haben alle das Update. Also Kernel> = 3.15. Das Docker, das Benutzer ausführen , muss auch das Docker.git-Commit 0434a2ce von @alexlarsson enthalten ("devmapper: Option blkdiscard hinzufügen und auf Raw-Geräten deaktivieren")

Wenn Sie "dmsetup-Ziele" ausführen, werden die Thin- und Thin-Pool-Zielversionen aufgelistet (vorausgesetzt, das dm-Thin-Pool-Kernelmodul ist geladen).

Vielen Dank für Ihre Aufmerksamkeit. Wir haben es letzte Woche den Standkollegen von Re: Invent gegenüber erwähnt.

@snitm also sollte die Ausgabe von dmsetup targets Ausgabe von check-config hinzugefügt werden?

@ Snitm

Wäre es möglich, einen automatisierten Test zu erstellen, der ein Thin-Provisioning-Device-Mapper-Gerät erstellt, einige Vorgänge darauf ausführt, bei denen kein freier Speicherplatz auf einem nicht gepatchten Kernel wiederhergestellt werden kann, und einen darauf basierenden Statuscode zu melden?

@SvenDowideit Sie hoffen, neue Kernel zu finden, bevor sie anfangen, DM Thin Provisioning auf Loopback zu verwenden?

@AaronFriel scheint extrem eng zu sein, um an diesem speziellen Fix so aufgehängt zu sein. Bei der Bereitstellung von DM Thin Provisioning auf Unternehmensebene geht es nicht nur darum, sicherzustellen, dass dieses Update vorhanden ist (unglückliche Realität). Das DM Thin Provisioning-Ziel hat seit dem Upstream von Commit 19fa1a675 zahlreiche Verbesserungen in Bezug auf Fehlerbehandlung, Leistung und Funktionen erfahren. All dies ist wichtig, wenn DM Thin Provisioning in der Produktion bereitgestellt wird.

Wenn ich also einen Schritt zurück trete, kann ich es genießen, für ein Unternehmen zu arbeiten, das versteht, dass mehrschichtige Produkte zusammen mit allen zugrunde liegenden Schichten entwickelt werden müssen. Und ich habe wenig Interesse daran, DM Thin Provisioning für N beliebige Kernel zu unterstützen, die mit Docker gepaart werden.

Und ich glaube fest daran, dass niemand DM Thin Provisioning mit Loopback-Geräten als Backing-Geräte verwenden sollte. Das war ein kompletter Hack, der ohne angemessene Zurückhaltung oder Sorge um "Wie sieht das in der Produktion aus?" In Docker verschmolzen wurde.

Ich habe festgestellt, dass für eine ordnungsgemäße Bereitstellung von Docker für DM Thin Provisioning die unternehmensorientierten Verwaltungsfunktionen erforderlich sind, die die lvm2-basierte Thin Provisioning-Konfiguration bietet. Vor diesem Hintergrund habe ich ständig daran gearbeitet, dass eine neue Hybrid-Management-Lösung funktioniert. Siehe PR:
https://github.com/docker/docker/pull/9006

Diese Arbeit hängt ab von:
1) lvm2> = 2.02.112
2) DM Thin-Pool-Zielversion> = v1.14.0 (auch bekannt als Änderungen in Linux-Next für Linux 3.19)

RHEL7.1 wird diese Änderungen haben. Und RHELAH (Atomic Host) wird es auch. Alle anderen Distributionen / Produkte, die Docker ordnungsgemäß für DM Thin Provisioning bereitstellen möchten, sollten dies ebenfalls tun.

@snitm yeah - Ich versuche, die Anzahl der Benutzer zu reduzieren, die von einem mysteriösen Bruch betroffen sind. Dann braucht jemand noch mehr Zeit, um zu erkennen, dass es sich um diesen obskuren Schmerz handeln könnte, und dann zu versuchen, den Benutzer zu bitten, es herauszufinden dass das Fehlen eines mysteriösen Patches das Problem ist.

und so im Zusammenhang mit Ihren verbleibenden Informationen - ich möchte die Anzahl der Kernel reduzieren, die diese schreckliche Überraschung verursachen werden :)

@SvenDowideit OK, ich habe in diesem Kommentar die Informationen angegeben, die Docker (oder seine Benutzer) verwenden können, um die Thin-Loop-Kompatibilität auf DM Thinp zu überprüfen: https://github.com/docker/docker/issues/3182#issuecomment -63706507

@snitm , @AaronFriel
Ich stoße auf dieses Problem bei AWS Beanstalk, Amazon AMI.
(Kein Platz mehr)
Linux ip-172-31-63-145 3.14.23-22.44.amzn1.x86_64 # 1 SMP Di 11.11. 23:07:48 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux

$ sudo docker version
Client-Version: 1.3.2
Client-API-Version: 1.15
Go-Version (Client): go1.3.3
Git Commit (Client): c78088f / 1.3.2
OS / Arch (Client): Linux / AMD64
Serverversion: 1.3.2
Server-API-Version: 1.15
Go-Version (Server): go1.3.3
Git Commit (Server): c78088f / 1.3.2

Ich erhalte immer noch diesen Fehler mit Ubuntu 14.04 und Docker 1.4.1.

Verlassen Sie sich nicht darauf, dass Thin-Pool- und Thin-Versionen> = 1.12.0 sind, um zu bedeuten, dass Sie in Ordnung sind. Wir führen CentOS 6.5-VMs mit den Kernel- und dmsetup-Zielen 2.6.32-431.29.2.el6.x86_64 aus Thin-Pool und Thin sind beide v1.12.0. Ich bin jedoch mit einer 40-GB-Datendatei festgefahren, die sich nicht selbst freigibt.

Welche Auswirkungen hat dies auf CentOS / RHEL 6.5 mit diesem Fehler? Sind Sie mit> = 100G freiem Speicherplatz einverstanden? Ich nehme an, dies füllt irgendwann eine beliebige Festplatte? Oder ist es auf 100G begrenzt?

Beachten Sie, dass in 6.5 nicht der neueste Kernel für Centos verfügbar ist. Ich würde ein einfaches 'yum-Update' auf 6.6 und einen Neustart empfehlen, um es mit dem Kernel 2.6.32-504.3.3 zu testen.

Stellen Sie sicher, dass die neuesten Kernel- und Distributionsupdates für CentOS 6 einwandfrei funktionieren und Speicherplatz freigeben.

ripienaar: Können Sie explizit angeben, welche CentOS 6- und Kernel-Version Sie verwenden? Ich möchte nur sicherstellen, dass ich bei der Weitergabe der Informationen alle Informationen habe, die ich benötige.

Vielen Dank.

Wie @reiz oben kommentiert hat, geschieht dies mit dem neuesten Docker von Ubuntu 14.04 +. dmsetup-Ziele zeigen auf einer unserer Instanzen einen Thin / Thin-Pool von Version 1.9.0 an (keine aktiven Docker-Container). dmsetup-Ziele zeigen auf einer ähnlichen Instanz mit aktiven Docker-Containern keine Thin-Einträge an. (Ich bitte nicht wirklich um Hilfe, sondern füge nur (hoffentlich nützliche) Daten hinzu.)

Grundlegende Betriebssysteme:

# 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

Verwendung:

# 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

Vor dem Zugriff auf diesen Kernel wurde kein Speicherplatz wiederhergestellt.

@jperrin erwähnt, dass dies mit dem Centos-Kernel 2.6.32-504.3.3 behoben werden kann. Ist bekannt, welcher Kernel-Commit (eine Reihe von Commits?) dieses Problem behebt?

Ich verwende derzeit eines von Oracle Enterprise Linux 3.8 UEK.

Gibt es eine Problemumgehung für diese Situation? Bei AWS ist es einfach, die Instanz neu zu erstellen, aber in der lokalen Entwicklungsumgebung ist es nicht gut zu bemerken, dass die / var-Partition aufgrund von Docker zu 90% im Besitz von Device-Mapper ist. Bald wird nicht einmal mehr Platz für Protokolle oder Tagebücher sein

@donrudo wie oben - Update auf die neuesten Centos 6 - den 504.3.3 Kernel.

Für Centos ist das in Ordnung, aber einige unserer Entwickler verwenden Fedora und andere OpenSuse.

Alle Änderungen an der DM Thin Provisioning werden zuerst im Upstream gesendet. Wenn Centos 6 also fixiert ist, ist es auch stromaufwärts fixiert. Die verschiedenen Distributionen müssen Korrekturen zurückziehen oder aggressiver neu starten.

@ripienaar Ich werde noch einmal fragen, wissen Sie, welche Kernel-Commits (oder welche Commits) für das

@lexinator nein

Ich sehe dieses Problem unter Ubuntu 14.04 Trusty und Kernel 3.13.0-36-generic. Eine mögliche Lösung besteht darin, AWS EBS-Speicher an das Verzeichnis anzuhängen, damit er unbegrenzt skaliert werden kann.

Leute, dieses Problem tut wirklich weh. CoreOS wechselt jetzt zu ext4 und bald werden wir all diese Probleme auch unter CoreOS haben.

Wie können Benutzer Docker (in dev oder prod) verwenden, während dieses Problem länger als ein Jahr nicht behoben ist? Jeder hat endlose Festplatten?

Ich glaube, sie wechseln zu ext4 für Overlay und nicht für Devmapper. Aber das ist
nur das Wort auf der Straße ...

Am Mittwoch, dem 28. Januar 2015, schrieb Sergey [email protected] :

Leute, dieses Problem tut wirklich weh. CoreOS wechselt jetzt und bald zu ext4
wird all diese Probleme auch unter CoreOS haben.

Wie Benutzer Docker (in dev oder prod) verwenden können, während dieses Problem nicht behoben ist
mehr als ein Jahr? Jeder hat endlose Festplatten?

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/docker/issues/3182#issuecomment -71800923.

Ich bin verwirrt. Mein Speicherplatz auf einer Google-Instanz beträgt nur 10 GB, aber die Größe von / var / lib / docker / devicemapper / devicemapper / data wird als 100 GB angezeigt. Ich kann keinen Speicherplatz zurückfordern, selbst nachdem alle Container und Bilder gelöscht wurden.

Es ist eine spärliche Datei. Verwenden Sie ls -sh anstelle von ls -l oder alternativ du -h

Ich kann dies unter Ubuntu 13.04 melden (wahrscheinlich nicht überraschend).

Ist dies derzeit die einzige wirkliche Problemumgehung, um genügend Speicherplatz bereitzustellen, um das Wachstum von Devicemapper zu antizipieren?

Dieser ganze Thread ist ziemlich lächerlich. Ein Debian-Benutzer nach dem anderen beschwert sich. Wenn Sie ein Problem feststellen, sollten Sie entweder zu einer ordnungsgemäß gewarteten Distribution wechseln oder mit Ihren Distribution-Betreuern zusammenarbeiten, damit diese das Problem beheben. Diese Distributionen halten nicht mit Korrekturen oder Verbesserungen Schritt. Ich werde alle zukünftigen Plädoyers für jemanden ignorieren, der dieses Problem in der Distribution $ foo behebt, da die Behebung bereits eindeutig vorgelagert ist (siehe CentOS oder RHEL). Bitte öffnen Sie einen Fehler gegen die betreffende defekte Distribution und verweisen Sie auf dieses Problem.

Es ist nicht so lächerlich, wenn Docker behauptet, auf den folgenden Plattformen Unterstützung zu haben:

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)

Wie können Sie einen pauschalen Support-Anruf für 14.04 erhalten, wenn dieses Problem offensichtlich so häufig auftritt? Docker sollte offensichtlich die pauschale Unterstützung für bestimmte Kernel auf bestimmten Distributionen einstellen.

Ich verwende CentOS und ein Kernel-Upgrade scheint das Problem mit der Verwendung von Devicemapper behoben zu haben.

Trotzdem danke für deine Arbeit @snitm.

Wenn Sie dieses Problem unter Ubuntu haben, stellen Sie sicher, dass Sie alte Docker-Images / Container ordnungsgemäß bereinigen. Ich stellte fest, dass mein Bereinigungsskript nicht ausgeführt wurde, als ich es dachte, und deshalb wurde so viel Speicherplatz benötigt.

`` `#! / Bin / bash

Löschen Sie alle Container

Docker rm $ (Docker ps -a -q)

Löschen Sie alle Bilder

Docker rmi $ (Docker-Bilder -q)
`` `

@ TylerMills Beachten Sie, dass docker rm die von den Containern erstellten Volumes nicht entfernt. Wenn Ihre Container Volumes verwenden, sollten Sie docker rm -v , damit Docker auch die Volumes entfernt.

@snitm Wir haben gerade auch etwas davon

Beachten Sie auch, dass ich auf dieses Problem gestoßen bin und Folgendes getan habe, um es zu beheben:

In meinem Fall besteht die einzige Möglichkeit, den Host daran zu hindern, in eine Kernel-Panik zu geraten, darin, den Docker-Prozess direkt abzubrechen (dh das Ausgeben von Docker-Befehlen würde in Panik geraten).

Beenden Sie dann manuell alle Prozesse mit den Devicemapper-Mounts mit diesem Befehl:

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

dann konnte ich alle Devicemapper-Mounts mit folgendem Mounten:

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

Diese Schritte gaben alle Dateideskriptoren frei, die es mir ermöglichten, den Speicherplatz zurückzugewinnen / Dateien zu löschen.

Zu diesem Zeitpunkt war es in meinem Fall sinnvoller, das Verzeichnis / var / lib / docker auf einen Mount mit mehr Speicherplatz zu verschieben und den Docker-Daemon so zu konfigurieren, dass mit dem Argument -g ein anderes Ausgangsverzeichnis verwendet wird

danke an Alexander Larsson über Adam Miller

Nach dem Kommentar von @dekz wäre es wahrscheinlich eine gute Idee, wenn die Installationsanleitung die Benutzer nicht anweisen würde, dass Kernelversionen ohne dieses Update akzeptabel sind, wie hier beschrieben: https://docs.docker.com/installation/ubuntulinux/

Danke @JohnMorales. Eine kleine Warnung von Docker wäre eine großartige Idee.

+1

+1

Wir haben vor kurzem etwas von diesem laufenden Ubuntu 14.04.2 LTS (3.16.0-30-generic) bekommen und sind immer noch auf der Suche nach einer Lösung. Es scheint, als ob entweder die Umstellung auf CentOS 6.6 (das angeblich den Kernel-Fix enthält) oder das Mounten eines Volumes mit einer größeren Festplatte die einzigen Lösungen sind.

Hat jemand, der Ubuntu ausführt, eine akzeptable Problemumgehung gefunden?

Ich bin damit einverstanden - Docker sollte dieses Problem beheben - es ist ein schwerwiegender Fehler, der Dokumentation und Warnmeldungen erfordert, damit nicht mehr Menschen naiv in dieselbe Falle tappen.

Ich stimme @natea zu
Ich habe das gleiche Problem mit redhat 6.5 und es wirft ein großes Fragezeichen auf, wenn Docker produktionsbereit ist und wir nach Alternativen suchen.
Es macht mir nichts aus, eine manuelle Problemumgehung zu finden, um das Problem zu lösen, aber im Moment sind mir keine machbaren bekannt.

@sagiegurarie Beachten Sie , dass wir die Anforderungen für CentOS aufgrund verschiedener Probleme mit 6.5 (und dem zugehörigen Kernel) auf 6.6

Also ist die Antwort auf Ausgabe 11643 nicht relevant? das heißt, wir können redhat 6.5 nicht verwenden?

@natea @sagiegurari Was für uns funktioniert, ist das von @TylerMills vorgeschlagene Handbuch "Fix"

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

Der Nachteil ist natürlich, dass Sie dann alle Bilder erneut abrufen und die Container erneut ausführen müssen.

@bkeroackdsc Ich erinnere mich, dass ich auch alle Container und Bilder zuvor gelöscht habe und das hat es nicht gelöst, aber ich werde es noch einmal versuchen.

Hallo! Ich würde gerne wissen, ob dieses Problem unter Ubuntu-15.04 noch besteht. Welches ist jetzt bei Linux-3.19 Kernel. Danke vielmals.

Wenn Sie auf Ubuntu-15.05 mit diesem Kernel sind, warum kein Overlay verwenden, ist es so
besser als Devicemapper

Am Donnerstag, den 7. Mai 2015 um 11:26 Uhr schrieb Dreamcat4 [email protected] :

Hallo! Ich würde gerne wissen, ob dieses Problem unter Ubuntu-15.04 noch besteht.
Welches ist jetzt bei Linux-3.19 Kernel. Danke vielmals.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/docker/issues/3182#issuecomment -99968299.

@ jfrazelle Oh richtig. Wie ist es Verwenden Sie Overlay? Ich bin (bis jetzt) ​​davon ausgegangen, dass die Overlay-Unterstützung ab dem 3.19-Kernel noch experimentell war.

Ja, ich benutze Overlay :) Wir hoffen, dass wir es in 1.7 verloren von uns nach oben bringen können
benutze es und liebe es

Am Donnerstag, den 7. Mai 2015, schrieb Dreamcat4 [email protected] :

@jfrazelle https://github.com/jfrazelle Oh, richtig. Wie ist es Tun
Sie verwenden Overlay? Ich bin (bis jetzt) ​​davon ausgegangen, dass
Die Overlay-Unterstützung war ab dem 3.19-Kernel noch experimentell.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/docker/issues/3182#issuecomment -99982543.

@sagiegurari Warum

@jperrin weil es nicht meine Entscheidung ist :)
Trotzdem versuche ich mit allen Teams zu überprüfen, ob Redhat 7 für die Produktion in Ordnung ist.

Dies scheint immer noch ein Problem unter CentOS7 (3.10.0-123.el7.x86_64) zu sein. Ich habe eine neue CentOS-Box eingerichtet und Docker v1.6.0 installiert. Die Devicemapper-Datendatei nimmt nach einem Sudo Docker-RMI niemals ab. Ich suche nach einer CentOS6.6-Box, um sie auszuprobieren.

v1.6.0 unter Ubuntu 14.04 schien sich positiv auszuwirken (über v1.5.0)

scheint auch bei centos 7 gut zu funktionieren, was ich wohl auch für redhat 7 sagen kann
Aber Redhat 6.5 ist es nicht, und ich schlage vor, dies in den Dokumenten anzugeben.

Dies sollte im neuesten Upstream-Docker funktionieren. Und der letzte Kommentar von @sagiegurari scheint dies zu implizieren. (funktioniert auf Centos 7).

Wenn dies der Fall ist, sollten wir diesen Fehler schließen.

Tritt dieses Problem also immer noch mit dem neuesten Docker auf? Wenn nicht, schließen wir es.

Nun ... mehr Tests durchzuführen scheint unsichere Ergebnisse zu liefern.
Sagen wir, es ist viel besser, aber es könnte immer noch undicht sein, nur viel langsamer.
Ich werde weitere Überprüfungen durchführen, um dies zu bestätigen.

@sagiegurari

Können Sie mir weitere Einzelheiten zu dem Problem und Ihrer Umgebung geben? Der Titel des Problems besagt, dass beim Löschen von Bildern / Containern kein Speicherplatz zurückgefordert wird und der neueste Upstream-Docker keine derartigen Probleme haben sollte.

Können Sie bitte Upstream-Docker verwenden, eine dynamische Binärdatei erstellen, ein neues Thin-Pool-Verzeichnis (in einem frischen Verzeichnis / var / lib / docker /) erstellen, ein Bild abrufen, es löschen und Docker-Informationen anzeigen, um festzustellen, ob Speicherplatz freigegeben wurde oder nicht.

Ich werde hoffentlich nächste Woche weitere Tests durchführen, um genauere Informationen zu erhalten.

Ich gebe zu, ich sehe es in unserer Build-Maschine, wo wir viele Images erstellen und entfernen (während des Builds selbst) + die Docker-Registrierung 2.0 ausführen (auf die wir immer die verschiedenen Images mit dem Tag 'latest' pushen) + einige Container ausführen Führen Sie erste Tests durch, damit alles einwandfrei funktioniert (der Test sollte eigentlich nicht auf diesem Computer ausgeführt werden, aber wir befinden uns in einem frühen Stadium, sodass wir viele Container erstellen / stoppen / rm erstellen).

Unsere Bilder sind wirklich groß, manchmal sehe ich eine virtuelle Größe über 2 GB. Wenn es also ein Problem gibt, zeigt es sich schneller als bei normalen Bildern, die normalerweise etwa 400 mg groß sind.

Wie auch immer, ich werde versuchen, nächste Woche einige Tests durchzuführen, um das Verhalten zu sehen und weitere Details bereitzustellen.

Erstellen Sie mit Docker Version 1.6.0 4749651 / 1.6.0 auf dem Linux-Kernel 3.14.35-28.38.amzn1.x86_64

Durch das Entfernen von Images wird der vom Docker beanspruchte Speicherplatz verringert.

@vbatts

Können wir dieses Problem schließen? Ich glaube nicht, dass wir im neuesten Docker das Problem haben, Bild- / Container-Speicherplatz aus oop-Dateien zurückzugewinnen. Wenn etwas Bestimmtes auftaucht, kann man eine neue Ausgabe mit bestimmten Details eröffnen.

@rhvgoyal Ich sehe keinen Grund, dieses Problem zu

@sagiegurari

Ich weiß nicht, was wir gewinnen, wenn wir das Thema offen halten. Ich weiß, dass es stromaufwärts repariert ist. Es gibt so viele offene Fragen. Die Leute benutzen sie als Dashboard, um die Beobachtungen zu notieren.

Ich bin der Meinung, dass es nur dann sinnvoll ist, ein Problem offen zu halten, wenn es ein wirklich reproduzierbares Problem gibt. Andernfalls wächst diese Liste von Themen immer weiter und es ist schwer herauszufinden, auf welche man sich konzentrieren soll.

Niemand hindert Sie daran, diesem Problem weitere Daten hinzuzufügen, sobald Sie diese haben.

@rhvgoyal Auf welches Tag beziehen Sie sich im letzten Upstream?

@rhvgoyal Sagen Sie das letzte Commit. Ich klone einfach den neuesten Git-Baum und teste das. Ist es wirklich wichtig?

So viele Probleme werden bei alten Docker-Releases und alten Kerneln gemeldet. Ich denke, der erste Schritt sollte sein, zu sehen, ob das gleiche Problem auf dem neuesten Docker und dem relativ neueren Kernerl sichtbar ist. Das gibt uns eine Vorstellung davon, ob es sich immer noch um ein Problem handelt oder um etwas, das in älteren Versionen nicht behoben wurde.

Wenn jemand zurückkommt und es in Zukunft liest, ja. Ich wollte wissen, in welcher Version es behoben wurde.

Bei Loopback-Geräten werden Rückwürfe ausgegeben. Es wurde tatsächlich vor langer Zeit gemacht. Ich denke, 1.6 sollte es haben.

@ Stanislavb mit 1.6 getestet und es hat bei ihm funktioniert.

Wenn Sie sich auf meinen ersten Kommentar in dieser Ausgabe beziehen, werden Sie sehen, dass ich es auch mit v1.6.0 auf centos7 versucht habe und das Problem immer noch hatte.

@alexDrinkwater

Ok, können Sie es reproduzieren? Welche Art von Thin Pool haben Sie verwendet (auf Loop-Geräten?). Haben Sie Docker neu gestartet oder passiert es beim ersten Start von Docker?

In einigen Fällen kann es vorkommen, dass Docker Loop-Geräte verwendet und Docker dann neu gestartet wird. Es kann vorkommen, dass der Pool nicht heruntergefahren wurde, weil ein Gerät irgendwo beschäftigt war. Beim Neustart Docker
Findet den Pool bereits dort und es ist nicht bekannt, dass Loopback-Geräte verwendet werden, und es wird kein Verwerfen ausgegeben. Ich frage mich, ob Sie in diese Situation geraten sind?

CentOS 7

Docker Version 1.6.2.el7, Build c3ca5bb / 1.6.2

Vor der Bildbereinigung

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

Nach einigem docker rmi

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

@alexDrinkwater

Ok, gerade habe ich ein Centos7-Image gestartet und Docker 1.6 ausprobiert, und ich sehe das Problem nicht. Hier sind die Schritte.

[ root @ centos7-generic ~] # Docker-Version
Client-Version: 1.6.0
Client-API-Version: 1.18
Go-Version (Client): go1.4.2
Git Commit (Client): 8aae715 / 1.6.0
OS / Arch (Client): Linux / AMD64
Serverversion: 1.6.0
Server-API-Version: 1.18
Go-Version (Server): go1.4.2
Git Commit (Server): 8aae715 / 1.6.0
OS / Arch (Server): Linux / AMD64

Es ist bereits ein Bild importiert.

[ root @ centos7-generic ~] # Docker-Bilder
REPOSITORY TAG IMAGE ID ERSTELLTE VIRTUELLE GRÖSSE
docker.io/fedora letzte ded7cd95e059 vor 2 Wochen 186,5 MB

Hier ist die Ausgabe der Docker-Informationen.

root @ centos7-generic ~] # Docker-Informationen
Behälter: 0
Bilder: 2
Speichertreiber: Devicemapper
Poolname: Docker-253: 1-50331788-Pool
Poolblockgröße: 65,54 kB
Sichern des Dateisystems: xfs
Datendatei: / dev / loop0
Metadatendatei: / dev / loop1
Verwendeter Datenraum: 525,5 MB
Datenraum Gesamt: 107,4 GB
Verfügbarer Datenraum: 20 GB
Verwendeter Metadatenraum: 892,9 kB
Metadaten-Speicherplatz Gesamt: 2,147 GB
Verfügbarer Metadaten-Speicherplatz: 2,147 GB
Udev-Synchronisierung unterstützt: true
Datenschleifendatei: / var / lib / docker / devicemapper / devicemapper / data
Metadaten-Schleifendatei: / var / lib / docker / devicemapper / devicemapper / metadata
Bibliotheksversion: 1.02.93-RHEL7 (28.01.2015)
Ausführungstreiber: native-0.2
Kernel-Version: 3.10.0-229.el7.x86_64
Betriebssystem: CentOS Linux 7 (Core)
CPUs: 2

[ root @ centos7-generic ~] # docker rmi fedora
Ohne Tag: Fedora: Neueste
Gelöscht: ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4
Gelöscht: 48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731

[ root @ centos7-generic ~] # Docker-Informationen
Behälter: 0
Bilder: 0
Speichertreiber: Devicemapper
Poolname: Docker-253: 1-50331788-Pool
Poolblockgröße: 65,54 kB
Sichern des Dateisystems: xfs
Datendatei: / dev / loop0
Metadatendatei: / dev / loop1
Verwendeter Datenraum: 307,2 MB
Datenraum Gesamt: 107,4 GB
Verfügbarer Datenraum: 20,22 GB
Verwendeter Metadatenraum: 733,2 kB
Metadaten-Speicherplatz Gesamt: 2,147 GB
Verfügbarer Metadatenplatz: 2,147 GB
Udev-Synchronisierung unterstützt: true
Datenschleifendatei: / var / lib / docker / devicemapper / devicemapper / data
Metadaten-Schleifendatei: / var / lib / docker / devicemapper / devicemapper / metadata
Bibliotheksversion: 1.02.93-RHEL7 (28.01.2015)
Ausführungstreiber: native-0.2
Kernel-Version: 3.10.0-229.el7.x86_64
Betriebssystem: CentOS Linux 7 (Core)
CPUs: 2

Hinweis Die Datennutzung ist von 525 MB auf 307 MB gesunken. Das Löschen eines Bildes brachte mir also den Platz zurück.

Ok, ich habe vergessen, die Größe der Schleifendatei vor und nach der Operation einzufügen. hier ist es.

  • Vor dem Bild ziehen.
    $ cd / var / lib / docker / devicemapper / devicemapper
    $ du -h Daten
    293 Millionen Daten
  • Nach dem Bild ziehen
    [ root @ centos7-generic devicemapper] # du -h Daten
    499 Millionen Daten
  • Nach dem Löschen des Bildes
    [ root @ centos7-generic devicemapper] # du -h Daten
    293 Millionen Daten

Meine Loop-Datei ist also nach dem Löschen des Bildes tatsächlich geschrumpft. Ich denke, darüber beschweren Sie sich.

@ Stanislavb

Verwenden Sie Loop-Dateien? Sie sind in Ihren Docker-Informationen nicht sichtbar. Ich denke, Sie haben das gleiche Problem, bei dem der Pool bereits beim Start des Dockers vorhanden war.

Können Sie die Größe der Loop-Backing-Dateien (/ var / lib / docker / devicemapper / devicemapper / data) überprüfen und sicherstellen, dass die Datei nach dem Löschen des Bildes verkleinert wird? (du-h).

@rhvgoyal
CentOS 7, Docker Version 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, die Größe der Loop-Geräte nimmt also tatsächlich ab.

Auch ich habe aus dem Code verifiziert. Wir werden verwerfen, auch wenn Docker beim Neustart bereits einen dünnen Pool gefunden hat.

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

Gemäß dem obigen Code werden Verwerfungen nur deaktiviert, wenn der Benutzer entweder ein Datenblockgerät oder einen Thin Pool übergeben hat. Da wir auch nicht bestanden haben, sind die Rückwürfe immer noch aktiv. Deshalb funktioniert es für Sie.

@alexDrinkwater Jetzt haben wir zwei Datenpunkte, die in 1.6 festgelegt sind. Haben Sie noch Bedenken, dieses Problem zu schließen?

CentOS 6.6

Docker Version 1.5.0, Build a8a31ef / 1.5.0

Vor der Bildbereinigung

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

Überprüfte Größe der Datendatei bei 1929 verbleibenden Bildern

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

Nach einigem docker rmi

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

Ok, also auch in 1.5 funktioniert es.

Ich habe das auf einer neuen Maschine getestet.

Docker Version 1.6.0, Build 8aae715 / 1.6.0

Vor dem Ziehen:

/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

nach dem ziehen:

/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

entferne Bild:

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

nach dem Löschen:

/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

Lassen Sie mich wissen, wenn Sie weitere Details zu meiner Maschine oder Versionen usw. haben.

@alexDrinkwater

Sieht so aus, als würden Sie ein separates Gerät auf / var montieren. Was ist das Dateisystem auf diesem Gerät und welche Mount-Optionen gibt es?

Kannst du mir auch folgendes geben?

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

Können Sie den einfacheren Fall versuchen, / var auf root selbst mit dem xfs-Dateisystem zu behalten? Ich versuche, das Problem ein wenig einzugrenzen.

@alexDrinkwater

Ich habe eine andere Festplatte mit ext4-Partition auf / var / lib / docker gemountet, sodass sich Loopback-Sicherungsdateien auf ext4 (anstelle von xfs) befinden und die Dinge immer noch für mich funktionieren.

/ dev / vdb1 on / var / lib / docker Typ ext4 (rw, relatime, seclabel, data = order)

Wirklich nicht sicher, was das Besondere an Ihrem Setup ist.

Um genau zu sein,

  • Vor dem Ziehen
    / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / docker
  • Nach dem Bild ziehen
    / dev / vdb1 9.8G 544M 8.7G 6% / var / lib / docker
  • Nach dem Bild löschen
    / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / docker

@alexDrinkwater

Der andere große Unterschied zwischen Ihrem Setup und meinem Setup ist die Kernel-Version. Ich verwende "3.10.0-229.el7.x86_64", während Sie anscheinend "3.10.0-123.el7.x86_64" verwenden. Können Sie Ihren Kernel aktualisieren und ausprobieren?

Danke für die Hilfe @rhvgoyal. Ich könnte den Kernel heute nicht aktualisieren. Aber hier sind die Einstellungen, nach denen Sie gefragt haben:

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

Ich habe keine benutzerdefinierten Speicheroptionen konfiguriert.

Fand es. Ich denke, es hat etwas mit dem ext3-Dateisystem zu tun. Ich kann das Problem auch sehen. Versuchen Sie es mit einem anderen Dateisystem, z. B. ext4 oder xfs, und Sie würden das Problem nicht haben.

/ dev / vdb1 on / var / lib / docker Typ ext3 (rw, relatime, seclabel, data = order)

Aus irgendeinem Grund funktioniert die Loopback-Datei im ext3-Dateisystem nicht. Möglicherweise ist ext3 alt genug, damit Loop-Discards nicht funktionieren.

Danke, sobald ich sah, dass das Dateisystem ext3 war, dachte ich, das könnte es sein. Ich denke, wenn Sie das Problem auf ext3 reproduzieren könnten, könnten wir dieses Problem als geschlossen bezeichnen. Es wird eine gute Referenz für andere sein.

Als Referenz waren meine Arbeitsbeispiele Docker 1.6.2 auf dem xfs-Dateisystem und Docker 1.6.0 und 1.5.0 auf ext4.

@vbatts

Können wir das schließen? Space Reclaim funktioniert unter xfs und ext4 einwandfrei. ext3 scheint zu alt zu sein, um es zu unterstützen.

@rhvgoyal @vbatts IIRC, es gibt eine Kompatibilitätsprüfung, die das zugrunde liegende Dateisystem überprüft. Vielleicht sollten wir einen Scheck für ext3 hinzufügen, wenn dies hier das Problem ist?

bearbeiten:
als Referenz; daemon / graphdriver / overlay / overlay.go # L115

Der Schleifentreiber verwendet fallocate (), um ein Loch in die Datei zu stanzen, wenn das Verwerfen eingeht. Die Linux-Manpage von fallocate () überprüft, ob es in ext3 nicht unterstützt wird.

/ *
Nicht alle Dateisysteme unterstützen FALLOC_FL_PUNCH_HOLE. Wenn ein Dateisystem den Vorgang nicht unterstützt, wird ein Fehler zurückgegeben. Der Vorgang wird auf mindestens den folgenden Dateisystemen unterstützt:
* XFS (seit Linux 2.6.38)
* ext4 (seit Linux 3.0)
* Btrfs (seit Linux 3.7)
* tmpfs (seit Linux 3.5)
* /

@ thaJeztah

Wenn jemand Docker auf ext3 ausführen möchte, sollten wir das zulassen. Nur dass sie keine Unterstützung für das Verwerfen erhalten, daher wird die Größe der Schleifendatei nicht verkleinert, wenn Bilder / Container gelöscht werden.

@rhvgoyal wie wäre es, dies in docker info ? Ähnlich wie Udev Sync Supported Ausgabe von

@ thaJeztah

Wir haben bereits einen Eintrag in der Docker-Info "Backing filesystem". Ich bin mir nicht sicher, warum es extfs heißt, anstatt genau über ext2 / ext3 / ext4 zu sprechen.

Möglicherweise sollte hier eine Warnung zum Startzeitpunkt in Protokollen angezeigt werden. Ähnlich wie bei der Warnung vor der Verwendung von Loop-Geräten für Thin Pools.

@ thaJeztah

Und ich denke, wir sollten es nur tun, wenn viele Menschen davon betroffen sind. Wenn nicht, erstellen wir einfach mehr Arbeit und Code und es lohnt sich möglicherweise nicht.

Die Struktur syscall.Statfs_t mit dem Feld Type in ext2, ext3 und ext4 gibt alle 0xef53 , und das ist es, was wir verwenden, um die Magie des Dateisystems zu erkennen.

Die Struktur syscall.Statfs_t mit dem Feld Typ in ext2, ext3 und ext4 gibt alle 0xef53 zurück, und das ist es, was wir verwenden, um die Magie des Dateisystems zu erkennen.

Schade. Es wäre gut gewesen, diese Informationen zu haben, um die Identifizierung gemeldeter Probleme zu erleichtern.

Ich denke, wir sollten das dann einfach schließen?

Schließen, da dies ein Problem ist, da ext3 veraltet ist. Bitte verwenden Sie ext4 oder xfs

Denken Sie, dass dies irgendwie besser in der Docker-Hauptdokumentation dokumentiert werden könnte?

Ob es sich um ein Problem mit dem Dateisystem handelt oder nicht, prüfen Sie, wie viel Verwirrung dies bei zwei kürzlich aufgetretenen Problemen verursacht hat.

Vielen Dank.

Wiederholen Sie die Ausgabe # 9786

@dbabits Ja, ich denke, die Erwähnung, dass ext3 einige Probleme hat, könnte in den Dokumenten erwähnenswert sein. Noch keine Ahnung, was ein geeigneter Ort wäre.

Habe das gleiche / ähnliche Problem mit XFS.
War auf dem Kernel "3.10.0-123.el7.x86_64", wurde aber jetzt auf "3.10.0-229.el7.x86_64" aktualisiert.

Alles wird gelöscht (Container, Bilder), aber die Daten enthalten noch 100 GB.
Irgendwelche Ideen, Hilfe?

[ root @ docker0101 ~] # ls -alh / data / docker / devicemapper / devicemapper /
insgesamt 80G
drwx ------ 2 root root 32 8. Juni 16:48.
drwx ------ 5 root root 50 Jun 9 07:16 ..
-rw ------- 1 root root 100G 16. Juli 21:33 Daten
-rw ------- 1 root root 2.0G 17. Juli 09:20 Metadaten

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

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

[ root @ docker0101 ~] # docker ps -a
BEHÄLTER-ID BILDBEFEHL ERSTELLTE STATUS-PORTS-NAMEN

[ root @ docker0101 ~] # Docker-Bilder -a
REPOSITORY TAG IMAGE ID ERSTELLTE VIRTUELLE GRÖSSE

[ root @ docker0101 ~] # Docker-Informationen
Behälter: 0
Bilder: 0
Speichertreiber: Devicemapper
Poolname: docker-253: 0-268599424-pool
Poolblockgröße: 65,54 kB
Sichern des Dateisystems: xfs
Datendatei: / dev / loop0
Metadatendatei: / dev / loop1
Verwendeter Datenraum: 85,61 GB
Datenraum Gesamt: 107,4 GB
Verfügbarer Datenraum: 40,91 MB
Verwendeter Metadatenbereich: 211,4 MB
Metadaten-Speicherplatz Gesamt: 2,147 GB
Verfügbarer Metadatenbereich: 40,91 MB
Udev-Synchronisierung unterstützt: true
Datenschleifendatei: / data / docker / devicemapper / devicemapper / data
Metadatenschleifendatei: / data / docker / devicemapper / devicemapper / metadata
Bibliotheksversion: 1.02.93-RHEL7 (28.01.2015)
Ausführungstreiber: native-0.2
Kernel-Version: 3.10.0-229.7.2.el7.x86_64
Betriebssystem: CentOS Linux 7 (Core)
CPUs: 4
Gesamtspeicher: 11,58 GiB
Name: docker0101

[ root @ docker0101 ~] # dmsetup-Tabelle
vg1-lvol0: 0 167772160 linear 8:16 2048
Docker-253: 0-268599424-Pool: 0 209715200 Thin-Pool 7: 1 7: 0 128 32768 1 skip_block_zeroing

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

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

[ root @ docker0101 ~] # rpm -qi docker
Name: Hafenarbeiter
Version: 1.6.2
Veröffentlichung: 14.el7.centos
Architektur: x86_64
Installationsdatum: Fr 17 Jul 2015 09:19:54 MESZ
Gruppe: Nicht spezifiziert
Größe: 33825026
Lizenz: ASL 2.0
Unterschrift: RSA / SHA256, Mi 24 Jun 2015 05:43:12 MESZ, Schlüssel-ID 24c6a8a7f4a80eb5
Quell-RPM: docker-1.6.2-14.el7.centos.src.rpm
Erstellungsdatum: Mi 24 Jun 2015 03:52:32 MESZ
Build-Host: worker1.bsys.centos.org

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

[ root @ docker0101 ~] # mount
/ dev / sda5 on / var Typ xfs (rw, relatime, attr2, inode64, noquota)
/ dev / mapper / vg1-lvol0 on / Datentyp xfs (rw, relatime, attr2, inode64, noquota)

@tomlux Der Devicemapper-Loopback-Modus, den Sie verwenden, ist hauptsächlich dazu gedacht, einfach mit Docker herumzuspielen. Bei ernsthafter Arbeit ist der Loopback langsamer und weist einige Einschränkungen auf. Ich würde wärmstens empfehlen, http://www.projectatomic.io/docs/docker-storage-recommendation/ zu lesen.

Sie erhalten eine bessere Leistung und werden solche Dinge nicht treffen, vorausgesetzt, Sie haben alle Systemupdates angewendet.

@ Tomlux

können Sie "-s" zu ls hinzufügen. Dadurch erhalten Sie tatsächliche Blöcke, die Daten- und Metadatendateien zugeordnet sind. Im Moment zeigt es die scheinbare Größe der Dateien.

Die Ausgabe von Docker-Informationen ist jedoch faszinierend. Es scheint eine hohe Nutzung zu zeigen.

ocr

@ Tomlux

Die tatsächliche Größe von Daten und Metadatendateien sieht also klein aus. Sie können "ls -alsh" verwenden, damit die Größen besser lesbar sind.

Die Größe der Datendateien scheint also etwa 79 MB und die Größe der Metadatendateien etwa 202 KB zu betragen.

Ich denke, dass die Statistiken von Thin Pool über die Anzahl der verwendeten Blöcke nicht richtig aussehen. Behebt ein Neustart des Computers das Problem?

Ich habe nach dem Kernel-Update einen Neustart ohne Erfolg durchgeführt.

image

Ok, Loop-Dateien sind also groß und Pool glaubt, dass es viele verwendete Blöcke gibt. Also benutzt etwas diese Blöcke. Kannst du mir eine Ausgabe von geben?

  • Docker ps -a
  • Docker-Bilder
  • ls / var / lib / dokcer / devicemapper / metadata / | wc -l
  • Docker herunterfahren und folgend ausführen.
    thin_dump / var / lib / docker / devicemapper / devicemapper / metadata | grep "device dev_id" | wc -l

Dies zeigt an, wie viele Thin-Geräte sich im Pool befinden.

Hmm,
Jetzt haben wir tote Container, aber keine Bilder.
Habe schon einen Neustart gemacht.

Scheint etwas falsch mit dem Devicemapper zu sein.
Ich möchte dieses Problem nicht als Spam versenden.
Ich kann auch "rm -f / var / lib / docker" und meine Container neu erstellen. Alles ist in Skripten geschrieben.

image

mache "dmsetup status"

Der Pool scheint in einem schlechten Zustand zu sein und muss höchstwahrscheinlich repariert werden.

image

Hallo,

Ich schien das gleiche Problem unter Ubuntu 14.04 zu haben. Die Ursache waren jedoch unerwünschte Volumes (vgl. Blog http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/). Befehl ausführen

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

viel Speicherplatz freigegeben.

Dies ist in keiner sinnvollen Weise behoben. Bei einer vollständig aktuellen Installation von Ubuntu 14.04.x ​​(der neuesten LTS-Version) und der neuesten Version von Docker (installiert über $ wget -qO- https://get.docker.com/ | sh ) wird Docker kontinuierlich Speicherplatz verlieren, ohne dass eine einfache Möglichkeit zur Rückforderung besteht. docker stop $(docker ps -q) && docker rm $(docker ps -q -a) && docker rmi $(docker images -q) nur wenig Speicherplatz frei.

Die einzige Möglichkeit, den gesamten Speicherplatz zurückzugewinnen, ist der folgende Hack:

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

Dazu müssen Sie möglicherweise alle benötigten Bilder erneut abrufen.

@bkeroackdsc Könnte dieser Speicherplatz auch mit "verwaisten" Volumes zusammenhängen?

Ich stimme @bkeroackdsc zu, dies ist nicht gelöst.
Ich fragte @rhvgoyal, warum er diesen Fall so sehr schließen wollte.
Am Ende habe ich Docker speziell wegen dieses Problems verlassen.
es tötet dieses Produkt.

verwaist oder nicht verwaist, es gibt keine gute, einfache Möglichkeit, Speicherplatz zu bereinigen.
Es muss eine Docker-CLI-Option für die Bereinigung, eine gute Statusbericht-CLI-Option und eine Art Überwachung für den Speicherplatz geben, da dieses Problem bei zu vielen Personen auf vielen Plattformen auftritt.

@bkeroackdsc @sagiegurari

Der Grund, den ich frage, ist, dass verwaiste Volumes nicht mit diesem Problem zusammenhängen.
nicht mit Devicemapper verwandt.

Verwaiste Volumes sind kein Fehler , sondern ein Missverständnis, das Volumes definiert haben
für einen Container werden automatisch gelöscht, wenn der Container gelöscht wird.
Dies ist _nicht_ der Fall (und beabsichtigt), da Volumes Daten enthalten können
Das sollte bestehen bleiben, nachdem ein Container gelöscht wurde.

_Um ein Volume zusammen mit einem Container zu löschen_, verwenden Sie docker rm -v [mycontainer] .
Volumenverwaltungsfunktionen werden hinzugefügt (siehe https://github.com/docker/docker/pull/14242 und https://github.com/docker/docker/issues/8363).
und ermöglicht es Ihnen, "verwaiste" Volumes zu verwalten.

Eine wachsende Größe von /var/lib/docker muss kein Hinweis sein
Dieser Devicemapper verliert Daten, weil die Größe dieses Verzeichnisses zunimmt
kann auch das Ergebnis von (verwaisten) Volumes sein, die nicht bereinigt wurden
vom Benutzer (Docker speichert alle seine Daten in diesem Pfad).

Ich hoffe wirklich, dass diese beiden Elemente die erforderlichen Funktionen bieten.
Ich habe den zweiten Punkt verstanden, aber der erste (# 14242) erklärt oben nicht, worum es geht, abgesehen davon, dass es sich um eine Volumen-API handelt (was bedeutet, dass ich nicht sicher bin, welche Funktionen es bietet).

@sagiegurari Es ist Teil der Anforderungen zur Implementierung des Image Volume Managements (es gibt einige andere offene PR-Probleme). Endziel ist es, Volumes in Docker zu einem erstklassigen Bürger zu machen, der unabhängig von den Containern, die sie verwenden, erstellt / gelöscht / verwaltet werden kann.

@swachter Vielen Dank, dass Sie diese

Wir haben das Problem mit dem undichten Volumen durch einen Dirty-Hack behoben, da dadurch verhindert wurde, dass der Docker-Daemon gestartet wurde, bevor das Zeitlimit für den Service auf unseren Docker-Hosts mit hoher Abwanderung abgelaufen war:

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

Dadurch wird das Problem behoben, ohne dass die zwischengespeicherten Bilder gelöscht werden.

Können wir das Problem von undichten Volumina in einer separaten Ausgabe diskutieren? Wenn Sie hier darauf eingehen, entsteht der Eindruck, dass es sich um ein Device Mapper-Problem handelt, obwohl dies nicht der Fall ist.

@tomlux @rhvgoyal

Sind Sie jemals zu einem Schluss gekommen, was in der CentOS 7-Box passiert? Mein Docker-Host ist fast identisch, und ich hatte das gleiche Problem. Ich folgte bis zu dem Punkt, an dem @rhvgoyal darum bat, den Befehl thin_dump auszuführen. Danach habe ich den Docker-Daemon gestartet und er wurde nicht gestartet. Ich habe gerade / var / lib / docker gelöscht und seitdem neu gestartet, aber ich wollte nur wissen, ob eine Lösung gefunden wurde, da ich (wie auch andere) möglicherweise erneut darauf stoßen.

[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

Ich habe die Quelle meines Problems gefunden. Ungeachtet dessen, wie es aussah, hatte es nichts mit den Problemen im Thread zu tun. Es ist nur auf ein Missverständnis mit der Funktionsweise von Docker zurückzuführen. Alle toten Container hielten immer noch an dem Speicherplatz fest, den sie während ihrer Ausführung zugewiesen hatten. Ich musste nur alle Container-Kadaver entfernen, um den Speicherplatz freizugeben. Ich erinnere mich, dass dies in diesem Thread auftauchte, aber ich dachte, es werden nur gemountete Volumes betrachtet, nicht der vom Container zugewiesene Speicherplatz.

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

@tomlux Dies könnte auch Ihr Problem gewesen sein, da Ihre Ausgabe von docker ps -a mehrere Dead Container zeigte.

docker rm gibt den Speicherplatz des Containers nicht frei

boot2docker neu in OS X VirtualBox. OS X vollständig gepatcht.

Ich baue einen fetten Container (47 GB) und es gibt ein Problem beim Anzeigen, dass ich den Container neu erstellen soll. Also habe ich den Container angehalten und Docker rm gemacht. Überprüfung mit Docker ssh'df -h', ich finde, dass die Festplattennutzung immer noch 47 GB beträgt. Der Container hat 75 GB.

Also muss ich die Docker-VM erneut beenden.

Können wir das schaffen?

@ awolfe-silversky Ist der Speicherplatz _in_ der VM zurückgegeben? Wenn es sich außerhalb der VM befindet, hängt dies möglicherweise nicht zusammen.

@ awolfe-silversky auch; Hast du das Bild auch entfernt? Das Entfernen nur des Containers hilft möglicherweise nicht viel, wenn das Bild noch vorhanden ist

@ awolfe-silversky In diesem Problem geht es um Devicemapper - und wenn Sie Docker-Machine / Boot2docker verwenden, ist die Wahrscheinlichkeit, dass aufs ausgeführt wird, sehr viel höher. Ich frage mich auch, ob Sie docker rmi Ihr großes Image haben.

Es lohnt sich, docker images und docker info auszuführen, um zu sehen, ob die Dinge wirklich so schlimm sind, wie Sie es klingen lassen :)

(Ja, wenn Sie noch die VM haben und das Image entfernt wird, sollten wir ein neues Problem öffnen und weiter debuggen, da Sie einen seltsamen Eckfall gefunden haben.)

Ich habe das Bild nicht entfernt. Es stammt aus einer internen Docker-Registrierung.
Ich habe ein awk-Skript verwendet, um die Größe der Bilder zu bestimmen - insgesamt 6,9 GB.

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

Es ist schmutzig, aber ich weiß, dass alle Bildgrößen in MB sind.

So habe ich versucht, die Verwendung zu diagnostizieren:

 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

Im Moment habe ich eine Box mit 0 Bildern.
docker volume ls -qf dangling=true zeigt nichts.
docker volume ls zeigt viele Volumes, die per Definition verwaist sind, da es keine Bilder gibt, die sie besitzen.
docker volume rm $(docker volume ls) zeigt viele solcher Nachrichten:

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

Das Device Mapper-Verzeichnis verbraucht 30 GiG.
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)

Warum wird bei der Standardinstallation die Speicheroption "stark entmutigt" verwendet?
Warum wurde mir das bei der Installation nicht gesagt?

Ich habe genau das gleiche Problem hier auf einer Amazon Linux EC2-Instanz.

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

In Fällen, in denen ich regelmäßig neue Docker-Images installiere, besteht die einzige Lösung darin, Folgendes zu tun:

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

Ich denke nicht, dass so etwas in einer Produktionsumgebung akzeptabel ist

einige zusätzliche Infos:

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

Da dieser Fehler seit Jahren besteht und anscheinend noch nicht geschlossen ist, können Sie in die Docker-Dokumentation über Devidemapper einfügen, wie die Sicherheit aller Docker-Informationen zerstört werden kann.
Ich meine, auf dieser Seite: https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
Setzen Sie so etwas wie "Cleaning Device Mapper" und wie es geht.

Ich werde versuchen, rm -rf / var / lib / docker zu machen, aber ich fühle mich dabei nicht wohl. Kann mir jemand sagen, ob es sicher ist?

Ich verwende Gentoo Linux in meinem täglichen Laptop und habe Docker zum Lernen ausprobiert, aber es füllt meine Festplatte und die Neuinstallation des gesamten Systems ist keine Option, da es sich nicht um eine VM handelt und die Neuinstallation von Gentoo Zeit braucht.

Danke für deine Arbeit.

@mercuriete Deinstallieren Entwicklungscomputer nur Docker, löschen Sie das Verzeichnis und installieren Sie es erneut. Funktioniert gut.

@ Ir-Fuel: Ich habe das gerade gemacht und jetzt habe ich das:

$ 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

Ich benutze service docker start

@ ir-Kraftstoff danke, es funktioniert gut. : +1:

Die Neuinstallation von Docker zur Freigabe von Speicherplatz ist die lächerlichste Antwort, die mir bei der Suche nach einer Lösung für dieses Problem begegnet ist. Dies ist nicht nur Zeitverschwendung, sondern in den meisten Umgebungen nicht einmal zulässig. Es ist ein guter Weg, um bezahlt zu werden, wenn Sie ein Stundenarbeiter sind.

Ich stimme vollkommen zu. Es ist erstaunlich, dass ein Produkt wie Docker immer wieder Speicherplatz verschlingt, ohne dass Sie etwas dagegen tun können, außer zu deinstallieren / neu zu installieren.

Beim erneuten Einchecken in dieses Problem hat sich ein weiteres Mal nichts geändert. +1

Dieses Problem ist als geschlossen markiert. Wir brauchen eine Lösung. Keine Problemumgehung, keine Neukonfiguration. Was ist der tatsächliche Status und welche Konfigurationseinstellungen sind damit verbunden? Das Löschen und Neuerstellen eines Docker-Produktionsknotens ist nicht zulässig.

Und was ist die Alternative? Wie gehen wir vor, um dies zu vermeiden?

Wenn die Verwendung dieser Funktion nicht empfohlen wird, warum ist sie stumm und standardmäßig?
einer? Wenn Sie sich nicht für Leute interessieren, die Devicemapper verwenden, bin ich vielleicht sogar in Ordnung
mit diesem. Aber informieren Sie den Benutzer darüber! Ist dir klar, wie viel
Kopfschmerzen Menschen haben aufgrund dieser erstaunlichen "Problemumgehung", auf die Sie sich festgelegt haben?
Am 23. Juni 2016, 16:32 Uhr, schrieb "kpande" [email protected] :

Umgehung: Vermeiden Sie die Verwendung des Docker-Geräte-Mapper-Treibers.
Unglücklicherweise.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/docker/issues/3182#issuecomment -228068397 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Es gibt immer rkt ...

Der allgemeine zickige, nicht hilfreiche Snark ist zweifellos der Grund, warum sich niemand aus dem Upstream darum kümmert, Ihnen die richtigen Antworten zu geben.

Niemand hat Sie gezwungen, Docker zu verwenden.

Das ist so, als würde Oracle einem Java-Entwickler aufgrund eines JVM-Fehlers sagen, dass er PHP verwenden soll. Das ist auch nicht im Einklang mit dem Elevator Pitch hier

Vor drei Jahren hat Docker eine esoterische Linux-Kernel-Technologie namens Containerisierung einfach und für jedermann zugänglich gemacht.

Ich bin sicher, viele Leute sind dankbar, dass Docker so gestartet ist und das nicht möglich gewesen wäre, ohne sich freiwillig bei der Community gemeldet zu haben. Es sollte jedoch nicht so schwer sein zuzugeben, dass es auch Probleme gibt, ohne implizit die Zeile "Ich bin ein Upstream-Mitwirkender, also halt die Klappe und hör zu" zu streichen, wenn jemand einen unwahrscheinlichen Punkt anspricht.

Warten. Ich habe ein Problem gemeldet und die Details meines Computers und der Einrichtung angegeben.
wozu ich nicht verpflichtet bin. Keiner von devteam hat auf meinen und andere Fehler reagiert
Berichte in einem halben Jahr. Jetzt habe ich diese Tatsache festgestellt, Sie nennen mein Verhalten
gehässig? Bist du überhaupt Open Source? Ich suche nach einem Go-Projekt, an dem ich arbeiten kann, und
Es wird kein Docker sein, das gebe ich dir. Ist das dein Ziel?
Am 23. Juni 2016 um 16:45 Uhr schrieb "gregory grey" [email protected] :

Wenn die Verwendung dieser Funktion nicht empfohlen wird, warum ist sie stumm und standardmäßig?
einer? Wenn Sie sich nicht für Leute interessieren, die Devicemapper verwenden, bin ich vielleicht sogar in Ordnung
mit diesem. Aber informieren Sie den Benutzer darüber! Ist dir klar, wie viel
Kopfschmerzen Menschen haben aufgrund dieser erstaunlichen "Problemumgehung", auf die Sie sich festgelegt haben?
Am 23. Juni 2016, 16:32 Uhr, schrieb "kpande" [email protected] :

Umgehung: Vermeiden Sie die Verwendung des Docker-Geräte-Mapper-Treibers.
Unglücklicherweise.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/docker/docker/issues/3182#issuecomment -228068397,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Wenn Sie dieses Problem weiterhin haben, öffnen Sie zunächst eine neue Ausgabe.

Warten. Ich habe ein Problem gemeldet

Sie haben auf eine 3 Jahre alte, geschlossene Ausgabe geantwortet. Nach der obigen Diskussion wurde das ursprüngliche Problem behoben. Ihr Problem kann das gleiche sein, benötigt aber mehr Forschung, um sicher zu sein; Die Fehler, die Sie melden, deuten darauf hin, dass es sich möglicherweise tatsächlich um etwas anderes handelt.

Ich empfehle wirklich, eine neue Ausgabe zu eröffnen und keine geschlossene Ausgabe zu kommentieren

lieferte die Details meiner Maschine und Einrichtung, zu denen ich nicht verpflichtet bin.

Sie sind nicht verpflichtet, aber ohne weitere Informationen ist es unwahrscheinlich, dass es gelöst wird. Wenn Sie also einen Fehler melden, fügen Sie bitte die angeforderten Informationen in die Vorlage ein:
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

Keiner der Entwickler hat innerhalb eines halben Jahres auf meine und andere Fehlerberichte geantwortet.

Wenn Sie "einer der Betreuer" meinen, denken Sie bitte daran, dass es fast 24000 Probleme und PRs gibt und weniger als 20 Betreuer , von denen viele dies neben ihrer täglichen Arbeit tun. Nicht jeder Kommentar wird bemerkt, besonders wenn es sich um ein geschlossenes Thema handelt.

Wenn diese Funktion nicht empfohlen wird - warum ist sie stumm und standardmäßig?

Dies ist die Standardeinstellung, wenn _aufs_, _btrfs_ und _zfs_ nicht unterstützt werden. Sie können die Priorität ermitteln, die bei der Auswahl der Treiber verwendet wird. Siehe daemon / graphdriver / driver_linux.go . Es ist immer noch über der Überlagerung, da es leider einige verbleibende Probleme mit diesem Treiber gibt, von denen einige Personen betroffen sein können.

Die automatische Auswahl eines Grafiktreibers dient nur dazu, "die Dinge zum Laufen zu bringen". Der beste Treiber für Ihre Situation hängt von Ihrem Anwendungsfall ab. Docker kann diese Entscheidung nicht automatisch treffen, daher muss der Benutzer sie konfigurieren.

Wenn Sie sich nicht für Leute interessieren, die Devicemapper verwenden, bin ich vielleicht sogar damit einverstanden.

Wenn ich die obige Diskussion zurückblicke, sehe ich, dass die vorgelagerten Devicemapper-Betreuer diese mehreren Male untersucht haben, um Benutzer bei der Meldung dieser Probleme zu unterstützen und das Problem zu beheben. Das Problem wurde für diejenigen behoben, die es gemeldet haben, oder in einigen Fällen davon abhängig, dass Distributionen Devicemapper-Versionen aktualisieren. Ich denke nicht, dass dies als "egal" angesehen werden kann.

Warum wird bei der Standardinstallation die Speicheroption "stark entmutigt" verwendet?

Das Ausführen auf Loop-Geräten ist in Ordnung, um Docker zum Laufen zu bringen, und derzeit die einzige Möglichkeit, Devicemapper automatisch einzurichten. Verwenden Sie für die Produktion und um insgesamt eine bessere Leistung zu erzielen, direct-lvm, wie im Abschnitt devicemapper im Benutzerhandbuch für Speichertreiber erläutert.

Warum wurde mir das bei der Installation nicht gesagt?

Das ist wirklich außerhalb des Rahmens für die Installation. Wenn Sie Software in der Produktion verwenden, sollten Sie davon ausgehen, dass Sie sich mit dieser Software vertraut gemacht haben und wissen, was für die Einrichtung für Ihren Anwendungsfall erforderlich ist. Einige Betreuer argumentierten sogar, ob die Warnung überhaupt ausgegeben werden sollte. Linux ist kein "Händchen haltend" -Betriebssystem (zeigt Ihre Distribution eine Warnung an, dass bei Verwendung von RAID-0 Datenverlust auftreten kann? Wenn in Ihrer Firewall Ports geöffnet sind?)

Ich zögere zutiefst, diesen alten Faden wiederzubeleben, aber es gibt immer noch keinen aussagekräftigen Rat, wie man dieses Problem auf einer vorhandenen Maschine umgeht, auf die dieses Problem stößt.

Dies ist meine größte Anstrengung bei einem tldr; für den gesamten Thread; Ich hoffe es hilft anderen, die diesen Thread finden.

Problem aufgetreten

Ihr Volume verfügt über eine erhebliche (und wachsende) Menge an Speicherplatz in /var/lib/docker und Sie verwenden ext3.

Auflösung

Du hast kein Glück mehr. Aktualisieren Sie Ihr Dateisystem oder sehen Sie unten blowing docker away .

Problem aufgetreten

Ihr Volume verfügt über eine erhebliche (und wachsende) Menge an Speicherplatz in /var/lib/docker und Sie verwenden ext3 nicht (z. B. System, das derzeit xfs oder ext4 verwendet).

Auflösung

Möglicherweise können Sie mithilfe von Standard-Docker-Befehlen Speicherplatz auf Ihrem Gerät zurückfordern.

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

Führen Sie die folgenden Befehle aus:

docker volume ls
docker ps
docker images

Wenn in keinem dieser Elemente etwas aufgeführt ist, sehen Sie unten blowing docker away .

Wenn Sie alte veraltete Bilder, nicht verwendete Container usw. sehen, können Sie eine manuelle Bereinigung durchführen mit:

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

Dies sollte einen Großteil des verborgenen Containerplatzes im Devicemapper zurückgewinnen.

Docker wegblasen

Hat nicht funktioniert? Du hast kein Glück mehr.

Ihre beste Wette zu diesem Zeitpunkt ist:

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

Dadurch werden alle Docker-Bilder zerstört. Stellen Sie sicher, dass Sie diejenigen exportieren, die Sie vor diesem Vorgang beibehalten möchten.

Lesen Sie letztendlich https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-Production. aber ich hoffe, dass dies anderen helfen wird, die diesen Thread finden.

Wenn Sie Probleme mit der Verwendung der oben genannten Ratschläge haben, öffnen Sie ein neues Ticket , das sich speziell mit dem aufgetretenen Problem befasst, und verknüpfen Sie es mit diesem Problem. poste es nicht hier.

rm -rf / var / lib / docker

Sie können auch nuke-graph-directory.sh verwenden .

Nachdem ich die Dateien wie oben angegeben entfernt habe, kann ich Docker nicht mehr starten:
02. März 04:53:40 pmdc001b dockerd [29522]: Fehler beim Starten des Daemons: Fehler beim Initialisieren des Grafiktreibers: open / var / lib / docker / devicemapper / devicemapper / data: Keine solche Datei oder kein solches Verzeichnis

Ich bin gerade auf dieses Problem unter CentOS 7.3 gestoßen und wollte keine Devmapper-Probleme debuggen, die seit mehr als 3 Jahren bestehen. Deshalb habe ich diesen DC / OS-Leitfaden befolgt, die Originalpakete gelöscht, auf Overlays umgestellt und jetzt scheint alles in Ordnung zu sein : https://dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/ (musste den ExecStart-Befehl für Docker-Version 17.03 ändern -> "dockerd --storage-driver = Überlagerung ")

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

(Das Löschen von Volumes, Bildern und Containern hat nicht geholfen. Das Löschen von Inhalten in / var / lib / docker führte zu dem von

Durch das Ausführen von docker system prune viel Speicherplatz auf meinen Computern freigegeben.

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

Nun, das ist irgendwie ... lahm.

In meinem Fall habe ich dieses Problem gefunden, nachdem ich Docker deinstalliert und das Verzeichnis /var/lib/docker gelöscht habe, sodass ich nicht das Äquivalent von service docker stop ... service docker start ausführen konnte.

Ich stellte fest, dass mein System den Speicherplatz für das Löschen von /var/lib/docker als freigegeben meldete (ich hatte ~ 14 GB in einer scheinbaren Schwebe).

Die Lösung hierfür ist, einfach Ihr Dateisystem neu zu laden. In meinem Fall habe ich gerade neu gestartet und der Speicherplatz wurde zurückgefordert.

Ich kann nicht glauben, dass es immer noch ein Problem ist! Komm schon Leute, das habe ich immer noch

@ shahaf600 Welche Docker-Version verwenden Sie? Siehe auch meinen Kommentar oben; https://github.com/moby/moby/issues/3182#issuecomment -228298975

Ohne Details gibt es nicht viel zu Ihrer Situation zu sagen. Ihr Fall könnte durch ein anderes Problem verursacht werden, aber zu einem ähnlichen Ergebnis führen.

gut

Nachdem ich eines dieser Müllstücke gekauft und den Zustand der Unterstützung gesehen hatte, gab ich es zurück.

Es gibt dein erstes Problem @misterbigstuff ... du hast etwas gekauft , das Open Source ist?

und gab es zurück

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen