+1, Saya sangat tertarik untuk mendengar beberapa diskusi tentang hal ini. Strategi saya sejauh ini

• berhati-hatilah dengan apa yang Anda bangun / tarik
• bersiaplah untuk meledakkan / var / lib / docker: neutral_face:

@AaronFriel , Anda menggunakan Docker versi apa? 0.7.1?

/ cc @regilero (tautkan juga ke # 2276)

Mulai dari / var / lib / docker baru:

# 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

Kemudian setelah buruh pelabuhan menarik busybox itu tumbuh sedikit:

# 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 _tidak_ membuat file lebih besar, tetapi membuat ruang kosong di kumpulan peta perangkat:

# 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

File loopback tidak bertambah jika kita mendownload gambar lagi:

# 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

Jadi, sepertinya kami gagal untuk melakukan sparsifikasi ulang file loopback ketika perangkat thinp membuang satu blok.

Namun, jika saya membuat file di dalam container fs image, itu _does_ merebut kembali ruang di file loopback.
Yaitu saya melakukan ini di gambar busybox:

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

Ini menumbuhkan file data dari 299 juta menjadi 344 juta. Tetapi ketika saya menghapus a_file.bin (dan menunggu sebentar) kembali ke 299M.

Jadi, bagi saya ini seperti bug devicemapper. Yaitu meneruskan membuang dari perangkat Thinp ke perangkat yang mendasarinya, tetapi tidak membuang saat melepas perangkat Thinp dari kolam.

Ini tampaknya menjadi masalah kernel, saya sedang mencari cara untuk mengatasinya dengan menggunakan BLKDISCARD, tetapi saya gagal. Lihat bug ini untuk beberapa detail: https://bugzilla.redhat.com/show_bug.cgi?id=1043527

Saya menggunakan solusi saya di https://github.com/alexlarsson/docker/tree/blkdiscard , tetapi kami masih meneliti apakah kami dapat melakukan yang lebih baik dari ini.

Komentar dm upstream tentang masalah ini:
http://device-mapper.org/blog/2013/12/17/thin-provisioning-and-discard-support/

Memiliki masalah ini di CentOS (2.6.32-358.23.2.el6.x86_64) dengan Docker 0.7.0, juga. Lama, tapi masalahnya tidak diisolasi ke Ubuntu.

Masalah yang sama di Arch GNU / Linux 3.12.6-1-ARCH, Docker versi 0.7.2.

Masih ada di 0.7.0 di CentOS.

Masih ada di 0.7.2 di ubuntu 12.04.3 LTS.

Banyak ruang dalam docker/devicemapper/devicemapper/data dan metadata , tetapi juga di docker/devicemapper/mnt

Sangat rapi bahwa saya belajar bahwa Anda dapat melihat sistem file kontainer di docker/devicemapper/mnt/SOME_KIND_OF_ID/rootfs

tetapi tidak rapi bahwa hard disk saya hampir habis dimakan dan hanya dapat diperbaiki oleh rmdir -r docker .

Saya mengalami masalah serupa saat menulis dukungan buruh pelabuhan untuk sistem rspec. VM pengujian saya (host buruh pelabuhan) memiliki drive 8GB dan setelah berulang kali membuat gambar tanpa menghapusnya, drive saya terisi. Tetapi setelah menghapus semua gambar dan kontainer, drive masih 100% penuh. Saya pikir itu adalah kesalahan ID-10T tetapi menyerah begitu saja dan menghancurkan VM secara bersamaan.

Masih ada di 0.7.5 di ubuntu 13.04.

Masalah ini telah diperbaiki oleh PR # 3256 yang baru-baru ini digabungkan. Perbaikan ini akan disertakan dalam rilis mendatang.

Saya menutup masalah ini sekarang karena perbaikan telah digabungkan ke master.

Catatan: Ini tidak _fully_ diperbaiki sampai Anda juga menjalankan kernel dengan http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= 6d03f6ac888f2cfc9c840db0b965436d32f1816d di dalamnya. Tanpa itu perbaikan buruh pelabuhan hanya sebagian.

Apa pekerjaan untuk menghilangkan ruang. Saya menggunakan rhel 6.5 dan mungkin perlu beberapa saat untuk mendapatkan kernel baru.

dikirim dari iPhone saya

Pada 21 Jan 2014, pukul 6:18 pagi, Alexander Larsson [email protected] menulis:

Catatan: Ini tidak sepenuhnya diperbaiki sampai Anda juga menjalankan kernel dengan http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= 6d03f6ac888f2cfc9c840db0b965436d32f1816d di dalamnya. Tanpa itu perbaikan buruh pelabuhan hanya sebagian.

-
Balas email ini secara langsung atau lihat di GitHub.

@logicminds Tidak ada cara super mudah untuk memulihkan ruang atm. Secara teknis, file loopback seharusnya dapat di-sparsifikasi secara manual. Tapi itu akan membutuhkan semua blok yang tidak digunakan untuk menjadi nol atau sesuatu untuk dengan mudah mendeteksi area yang jarang, yang tidak dilakukan pada penghapusan perangkat thinp.

@alexlarsson Apakah ini juga mempengaruhi OEL 6.5? OEL 6.5 sebenarnya menggunakan kernel linux uek 3.8 dan karena saya memiliki opsi antara beralih dari kernel 2.6 ke 3.8, ini mungkin merupakan peralihan sederhana bagi saya.

@logicminds Saya bahkan tidak tahu apakah komit itu ada di kernel upstream. Tautan tersebut berasal dari pohon pemeta perangkat. Ini jelas bukan di 3.8.

Saya sedang membuat alat seperti fstrim yang dapat digunakan untuk mendapatkan kembali ruang.

Masalah @alexlarsson https://bugzilla.redhat.com/show_bug.cgi?id=1043527 telah ditutup, secara resmi karena "data tidak mencukupi". Apakah itu berarti tambalan tidak akan berhasil masuk ke kernel? Apakah masih dibutuhkan?

@vrvolle Patch yang membuat solusi yang digunakan buruh pelabuhan sudah upstream. Tampaknya tidak ada pekerjaan upstream untuk membuat solusi tersebut tidak diperlukan.

Saya masih memiliki masalah ini dengan buruh pelabuhan 0.9 di centos 6.5 dengan kernel 2.6.32 default.

Saya tidak yakin untuk mengerti apa yang Anda katakan sebelumnya tentang commit ini ke device-mapper. Bisakah Anda mengonfirmasi bahwa jika saya memigrasi kernel ke 3.8, bug ini harus diselesaikan?

Terima kasih sebelumnya.

@ nicolas-van Tidak, Anda memerlukan komit ini: https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316

Ada di 3,14, dan mungkin dalam berbagai 3.xy backport

Saya telah menginstal beberapa waktu lalu buruh pelabuhan untuk membangun sebuah gambar dan menjalankannya dalam sebuah wadah. Kemudian beberapa waktu kemudian saya menghapus semua gambar dan kontainer, termasuk aplikasi buruh pelabuhan dan folder utama.
Sekarang saya menyadari bahwa dari total 4GB / 24GB gratis / bekas (df -h), perintah du / -sh hanya melaporkan 10GB sehingga 10Gb lainnya tidak diperhitungkan. Itu lebih kecil dari ukuran gambar temp yang dihasilkan dengan buruh pelabuhan, mungkinkah itu terkait dengan bug ini. Saya telah menggunakan centos 6.5 dan buruh pelabuhan 0.9.

Saya telah menghapus buruh pelabuhan dengan yum, dan devs dari / dev / mapper / docker * dengan dmsetup, dan juga rm / var / lib / docker -Rf, dan masih laporan disk dengan df 10gb yang digunakan yang tidak dapat saya temukan di mana pun.

@Jacq Ada kemungkinan beberapa file masih tetap hidup oleh proses yang memiliki deskriptor file yang terbuka untuk itu. Apakah kamu reboot? Itu akan memastikan itu tidak terjadi.

Saya menjalankan Linux 3.14.4-1-ARCH, dan buruh pelabuhan 0.11.1, menghapus semua gambar dan kontainer.
dan file / var / lib / docker / devicemapper / devicemapper terjebak, memakan sekitar 1,5GB

berikut adalah hasil dari setelah saya mengutak-atik beberapa barang mongodb, saya kira ukuran file harus dialokasikan secara jarang karena / var saya bahkan tidak sebesar itu.

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

Permisi, apakah bug sudah diperbaiki sekarang? Saya menemukannya di Gentoo.

@bolasblack Saya menjalankan gentoo dan mengalami masalah ini. Apakah Anda menemukan sesuatu?

Saya menggunakan gentoo-sources terbaru yaitu 3.14.14 untuk x86_64. Saya melihat https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316?diff dan patch itu diterapkan ke sumber saya. Saya memiliki Docker Docker versi 1.1.0, membangun 79812e3.

@alexlarsson Terima kasih telah mengembalikan perhatian Anda ke masalah tertutup ini setelah sekian lama. Sepertinya itu masih menimbulkan masalah. Ada kabar tentang status # 4202?

Ini masih menjadi masalah! Saya pikir saya akan beralih kembali menggunakan AUFS untuk saat ini.

@daniellockard AUFS tampaknya tidak digunakan lagi secara tidak resmi: # 783 dan # 4704, semoga berhasil.

Astaga ... kemana perginya 25GB itu? Oh, ke dalam satu file itu .... Saya menjalankan kernel 3.16.2 f20 64b

Tautan ke 'solusi' rusak ... apa itu? dan apakah kernel saya mendukungnya ... jika Torvalds berkomitmen pada 3.14, saya curiga fedora akan melihatnya di 3.16, bukan?

+1

+1

+1

+1 Sepertinya masih terjadi di Ubuntu Trusty, 3.13.0-36-generik dengan Docker versi 1.3.1, build 4e9bbfa

+1 juga di Trusty. Apakah perlu memeriksa 14.10 yang menggunakan 3.16?

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

Memberi tag pada pelaku teratas karena ini konyol. Perlu ada percakapan publik tentang hal ini dan pengakuan dari tim Docker bahwa bug ini dapat menyebabkan container atau sistem yang rusak secara berkala dan perlu dibuat ulang. Saya sudah mengenal beberapa orang yang harus mengimplementasikan solusi devops yang gila seperti secara berkala menggambarkan ulang host Docker mereka setiap minggu atau dua minggu karena bot build mereka memiliki banyak churn. Saya memperkenalkan masalah ini hampir setahun yang lalu dan sejauh yang saya tahu, tidak ada solusi pasti yang dibuat, dan kernel lama yang seolah-olah didukung tidak.

Tim Docker: lakukan penelitian untuk menentukan versi kernel mana yang terpengaruh, mengapa, dan tambalan apa yang akan memperbaiki masalah, dan dokumentasikan. Publikasikan informasi itu bersama dengan versi kernel apa yang Anda dukung, karena saat ini konsumen Docker mendapatkan sedikit masalah ini berulang kali, sebagaimana dibuktikan oleh fakta bahwa saya masih mendapatkan email tentang masalah ini setiap satu atau dua minggu. Serius, ini adalah masalah utama dan ini menjadi masalah sejak sebelum 1.0.

Seperti yang saya lihat, ada beberapa kemungkinan opsi untuk memperbaiki masalah ini dengan cara yang memuaskan yang akan menghentikan email yang terus saya dapatkan untuk +1 tentang masalah ini:

1. Beri tahu pengguna saat Device-Mapper digunakan pada kernel yang tidak didukung dan berikan mereka instruksi mendetail tentang cara mendapatkan kembali ruang, dan jika memungkinkan secara otomatis mengatur proses untuk melakukan ini di Docker. Saya akan menyarankan bahwa pemberitahuan ini juga harus dikeluarkan saat menggunakan CLI buruh pelabuhan terhadap host yang menderita masalah ini, sehingga ketika mengelola host jarak jauh dari CLI buruh pelabuhan, pengguna diberi tahu bahwa beberapa host mungkin tidak mendapatkan kembali ruang dengan benar.
2. Perbaiki masalahnya (entah bagaimana). Saya tidak cukup tahu tentang pengembangan kernel untuk mengetahui apa saja yang diperlukan, tetapi, berdasarkan pembacaan pemula saya, saya menyarankan ini:

Sebuah. Karena device mapper adalah modul kernel, bawalah versi yang berfungsi dan berfungsi ke pohon sumber Docker sebagai sesuatu seperti dm-docker

b. Buat perubahan yang memadai pada dm-docker agar dapat hidup berdampingan dengan pembuat peta perangkat.

c. Pada platform yang terpengaruh, instal modul kernel dm-docker saat penginstalan dan gunakan dm-docker secara default.

1. Ubah dokumen instalasi Anda dan situs docker.com untuk menyertakan peringatan pada versi kernel yang terpengaruh, dan tambahkan pemeriksaan runtime ke paket untuk memverifikasi operasi pemeta perangkat yang benar, dan jika tidak melaporkannya kepada pengguna.

Ini seharusnya menjadi masalah pemblokiran untuk rilis stabil berikutnya dari Docker, karena itu tidak dapat diterima untuk terus melakukan punting dan membuat pengguna kesulitan.

Secara pribadi saya melihat CoreOS sebagai satu-satunya distro Linux yang stabil untuk Docker (sampai masalah ini teratasi).

Tim Docker: Saya tahu bahwa masalah ini bukan disebabkan oleh komponen Anda, tetapi tolong, bantu kami untuk menggunakan perangkat lunak Anda juga di distro Linux lainnya. Akan baik-baik saja jika Anda juga dapat menyebutkan masalah ini sebagai batasan Docker yang terkenal dalam dokumentasi, sehingga orang lain tidak akan membuang waktu mereka.

Terima kasih!
Martin

+1 sesuatu perlu dilakukan.

Akan lebih baik jika ada sesuatu yang lebih jelas untuk masalah ini daripada harus menggali daftar masalah github (tertutup). Butuh waktu lama untuk benar-benar menemukan bahwa ini adalah masalah yang mendasarinya dan alangkah baiknya melihat visibilitas masalah ini.

Kami, pengembang Pemeta perangkat hulu (saya dan Joe Thornber) benar-benar menyadari _zero_ bahwa masalah ini masih menjadi masalah bagi orang-orang. Kami segera memperbaiki masalah tersebut setelah kami menyadarinya (oleh @alexlarsson pada Des 2013) dan menandainya untuk dimasukkan dalam _all_ kernel stable pada saat itu, lihat: http://git.kernel.org/linus/19fa1a6756ed9e9 ( "dm tipis: perbaiki, buang dukungan ke blok yang dibagikan sebelumnya")

Joe Thornber baru saja diberi tahu bahwa @alexlarsson menerapkan trim-pool dalam kode go buruh pelabuhan. Ketika saya menunjukkannya kepadanya, dia mulai menerapkan alat 'thin_trim' mandiri yang tepat yang akan didistribusikan sebagai bagian dari paket 'device-mapper-persistent-data' (setidaknya di Fedora, CentOS, RHEL), lihat:
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

JADI ... semua dikatakan, pengguna yang menjalankan kernel yang tidak memiliki upstream commit 19fa1a6756ed9e9 ("dm thin: fix discard support to a before shared block") perlu memperbaikinya dengan menjalankan kernel yang lebih baik didukung. Saya dapat dengan mudah mengirim catatan ke [email protected] untuk mengisi ulang perbaikan ke kernel stabil yang tidak memilikinya. Jadi tolong beri tahu saya, jika ada, kernel stabil mana yang tidak memiliki perbaikan ini.

Ke depan, kami ingin buruh pelabuhan untuk menjalankan 'thin_trim' secara berkala terhadap perangkat kumpulan tipis yang digunakan buruh pelabuhan. Tapi kita akan menyeberangi jembatan itu setelah 'thin_trim' tersedia secara luas di distro.

@shabbychef @daniellockard tidak, AUF tidak digunakan lagi - pertama, hanya satu dari masalah itu yang ditutup, dan membaca terus, saya rasa https://github.com/docker/docker/issues/783#issuecomment -38731137 adalah layak dibaca:

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 dapatkah Anda menambahkan sesuatu ke hack/check_config.sh untuk memberi tahu pengguna bahwa kernel mereka tidak memiliki tambalan ini?

@SvenDowideit sayangnya perubahan yang dimaksud tidak teridentifikasi di kernel arbitrer. Sebagai permulaan, commit 19fa1a6756ed9e9 tidak menabrak versi thin-pool target. Tetapi bahkan jika itu terjadi, versi itu akan bervariasi di semua kernel stabil (dan itulah sebabnya mengapa tonjolan versi dalam komit 'stabil' itu buruk .. karena ini menyebabkan pengeditan manual semua kernel yang komit mendapat backport ke).

TAPI, pengguna yang memiliki versi target kumpulan tipis dan tipis> = 1.12.0 semuanya akan mendapatkan perbaikan. Jadi kernel> = 3.15. Pekerja galangan yang dijalankan pengguna juga perlu menyertakan

FYI, menjalankan 'dmsetup target' akan mencantumkan versi target thin-pool (asalkan modul kernel dm-thin-pool dimuat).

Terima kasih atas perhatiannya. Kami menyebutkannya ke booth dudes di Re: Invent minggu lalu.

@snitm jadi dmsetup targets output harus ditambahkan ke output check-config ?

@tokopedia

Mungkinkah membuat pengujian otomatis yang akan membuat perangkat pemeta-perangkat yang disediakan tipis, melakukan beberapa operasi padanya yang akan gagal mendapatkan kembali ruang kosong pada kernel yang belum ditambal, dan melaporkan kode status berdasarkan itu?

@SvenDowideit Anda berharap untuk menangkap kernel baru yang menyinggung sebelum mereka mulai menggunakan penyediaan tipis DM di atas loopback?

@AaronFriel tampaknya sangat sempit dalam lingkup untuk begitu terpaku pada perbaikan khusus ini. Ada lebih banyak penerapan thin-provisioning tingkat perusahaan daripada memastikan perbaikan ini ada (kenyataan yang tidak menguntungkan). Target penyediaan tipis DM telah melihat banyak penanganan kesalahan, peningkatan kinerja dan fitur sejak commit 19fa1a675 naik ke atas. Semuanya penting saat menerapkan penyediaan tipis DM dalam produksi.

JADI mengambil langkah mundur, saya kebetulan dapat menikmati bekerja untuk perusahaan yang memahami bahwa produk berlapis perlu dikembangkan bersama dengan semua lapisan yang mendasarinya. Dan saya memiliki sedikit minat dalam mendukung penyediaan tipis DM untuk N kernel sewenang-wenang yang dipasangkan dengan buruh pelabuhan.

Dan saya kebetulan _strongly_ percaya bahwa tidak ada yang boleh menggunakan penyediaan tipis DM dengan perangkat loopback sebagai perangkat pendukung. Itu adalah peretasan lengkap yang bergabung menjadi buruh pelabuhan tanpa pengekangan yang tepat atau perhatian untuk "seperti apa ini dalam produksi?".

Saya telah menyadari bahwa penerapan buruh pelabuhan yang tepat pada penyediaan tipis DM memerlukan fitur manajemen berorientasi perusahaan yang disediakan oleh konfigurasi penyediaan tipis berbasis lvm2. Jadi dengan mengingat hal itu, saya terus bekerja untuk membuat solusi manajemen hybrid baru berfungsi, lihat PR ini:
https://github.com/docker/docker/pull/9006

Pekerjaan ini bergantung pada:
1) lvm2> = 2.02.112
2) DM versi target kumpulan tipis> = v1.14.0 (alias perubahan yang dipentaskan di linux-next untuk penyertaan Linux 3.19)

RHEL7.1 akan memiliki perubahan ini. Dan RHELAH (Atomic Host) juga akan melakukannya. Distro / produk lain yang ingin menerapkan buruh pelabuhan dengan benar di DM thin-provisioning juga harus.

@snitm yeah - Saya mencoba untuk mengurangi jumlah pengguna yang terkena kerusakan misterius, yang kemudian membutuhkan lebih banyak waktu bagi seseorang untuk menyadari bahwa itu bisa jadi rasa sakit yang tidak jelas ini, lalu mencoba meminta pengguna untuk mencari tahu bahwa kurangnya beberapa patch misteri adalah masalahnya.

dan seterusnya dalam konteks info Anda yang tersisa - Saya ingin mengurangi jumlah kernel yang akan menyebabkan kejutan mengerikan ini :)

@SvenDowideit Oke, saya memberikan info yang dapat digunakan oleh buruh pelabuhan (atau penggunanya) untuk memeriksa penipisan DM pada kompatibilitas loopback di komentar ini: https://github.com/docker/docker/issues/3182#issuecomment -63706507

@nitaputri , @AaronFriel
Saya mengalami masalah yang tampaknya seperti ini di AWS beanstalk, Amazon AMI.
(Kehabisan ruang)
Linux ip-172-31-63-145 3.14.23-22.44.amzn1.x86_64 # 1 SMP Sel 11 Nov 23:07:48 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux

$ sudo versi buruh pelabuhan
Versi klien: 1.3.2
Versi API Klien: 1.15
Go versi (klien): go1.3.3
Git commit (klien): c78088f / 1.3.2
OS / Arch (klien): linux / amd64
Versi server: 1.3.2
Versi API Server: 1.15
Go versi (server): go1.3.3
Git commit (server): c78088f / 1.3.2

Saya masih mendapatkan kesalahan ini dengan Ubuntu 14.04 dan Docker 1.4.1.

Jangan mengandalkan thin-pool dan versi thin menjadi> = 1.12.0 yang berarti Anda baik-baik saja. Kami menjalankan VM CentOS 6.5 dengan kernel 2.6.32-431.29.2.el6.x86_64 kernel dan target dmsetup melaporkan bahwa thin-pool dan thin keduanya v1.12.0. Namun, saya terjebak dengan file data 40GB yang tidak membebaskan dirinya sendiri.

Apa implikasi menjalankan ini di CentOS / RHEL 6.5 dengan bug ini? Apakah Anda setuju dengan> = 100G ruang kosong. Saya berasumsi ini akhirnya mengisi disk ukuran apa pun? Atau apakah itu dibatasi pada 100G?

Perlu diingat bahwa 6.5 tidak memiliki kernel terbaru yang tersedia untuk centos. Saya akan merekomendasikan 'pembaruan yum' sederhana ke 6.6 dan reboot untuk menguji dengan kernel 2.6.32-504.3.3.

Konfirmasikan kernel dan pembaruan distro terbaru untuk CentOS 6 berfungsi dengan baik dan lepaskan ruang.

ripienaar: Dapatkah Anda secara eksplisit menyatakan CentOS 6 dan versi kernel yang Anda gunakan? Saya hanya ingin memastikan bahwa saat saya meneruskan info, saya memiliki semua info yang saya butuhkan.

Terima kasih.

Seperti yang dikomentari oleh @reiz di atas, ini terjadi dengan Ubuntu 14.04 + buruh pelabuhan terbaru. Target dmsetup menunjukkan thin-pool v1.9.0 di salah satu instance kami (tidak ada container buruh pelabuhan yang aktif.) Target dmsetup tidak menampilkan entri tipis apa pun pada instance serupa dengan container buruh pelabuhan aktif. (Saya tidak benar-benar meminta bantuan dalam hal ini, hanya menambahkan data (semoga bermanfaat).)

Hal-hal dasar OS:

# 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

Pemakaian:

# 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

Sebelum masuk ke kernel itu, itu tidak akan memulihkan ruang.

@jperrin menyebutkan ini diselesaikan menggunakan centos kernel 2.6.32-504.3.3. apakah diketahui komitmen kernel mana (set komit?) yang menyelesaikan masalah ini?

Saat ini saya menggunakan salah satu Oracle Enterprise Linux 3.8 UEK.

Apakah ada solusi untuk situasi ini? di AWS mudah untuk hanya membuat ulang instans, tetapi di lingkungan pengembangan lokal tidak baik untuk memperhatikan partisi / var dimiliki oleh 90% oleh device-mapper karena buruh pelabuhan; segera tidak akan memiliki ruang bahkan untuk log atau jurnal

@donrudo seperti di atas - perbarui ke centos 6 terbaru - kernel 504.3.3.

Tidak apa-apa untuk centos tetapi beberapa dev kami menggunakan Fedora dan OpenSuse lainnya.

Semua perubahan penyediaan tipis DM dikirim ke upstream terlebih dahulu. Jadi jika Centos 6 diperbaiki, itu juga diperbaiki di hulu. Berbagai distro perlu menarik perbaikan kembali atau melakukan rebase dengan lebih agresif.

@ripienaar Saya akan bertanya lagi, apakah Anda tahu komit kernel (atau kumpulan komit) mana yang diperlukan untuk perbaikan?

@lexinator tidak

Saya melihat masalah ini di Ubuntu 14.04 Trusty dan kernel 3.13.0-36-generic. Solusi yang memungkinkan adalah melampirkan penyimpanan AWS EBS ke direktori sehingga dapat diskalakan tanpa batas.

Teman-teman, masalah ini sangat menyakitkan. CoreOS sekarang pindah ke ext4 dan segera kita akan mengalami semua masalah ini di CoreOS juga.

Bagaimana orang dapat menggunakan buruh pelabuhan (di dev atau prod) sementara masalah ini tidak diperbaiki selama lebih dari satu tahun? Setiap orang punya disk tak berujung?

Saya yakin mereka pindah ke ext4 untuk overlay bukan devmapper. Tapi itu
hanya kata di jalan ...

Pada hari Rabu, 28 Januari 2015, Sergey [email protected] menulis:

Teman-teman, masalah ini sangat menyakitkan. CoreOS sekarang dan segera pindah ke ext4
akan mengalami semua masalah ini di CoreOS juga.

Bagaimana orang dapat menggunakan buruh pelabuhan (di dev atau prod) sementara masalah ini belum diperbaiki untuk
lebih dari setahun? Setiap orang punya disk tak berujung?

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/3182#issuecomment -71800923.

Saya bingung. Ruang disk saya pada instance Google hanya 10G, tetapi ukuran / var / lib / docker / devicemapper / devicemapper / data ditampilkan sebagai 100G. Saya tidak dapat memperoleh kembali ruang bahkan setelah menghapus semua container dan gambar.

Ini file yang jarang. Gunakan ls -sh alih-alih ls -l , atau sebagai alternatif, du -h

Saya dapat melaporkan ini di Ubuntu 13.04 (mungkin tidak mengherankan).

Apakah saat ini satu-satunya solusi nyata untuk ini adalah menyediakan ruang disk yang cukup untuk mengantisipasi pertumbuhan peta perangkat?

Seluruh utas ini cukup konyol. Satu demi satu pengguna Debian mengeluh. Jika Anda melihat masalah, Anda harus beralih ke distro yang dipelihara dengan baik atau bekerja dengan pengelola distro Anda agar mereka dapat memperbaiki masalah tersebut. Distro ini tidak mengikuti perbaikan atau peningkatan. Saya akan mengabaikan semua permohonan di masa mendatang bagi seseorang untuk memperbaiki masalah ini di distro $ foo mengingat perbaikannya jelas sudah upstream (lihat CentOS atau RHEL). Silakan buka bug terhadap distro rusak yang dimaksud dan rujuk masalah ini.

Tidaklah konyol ketika Docker mempertahankan bahwa mereka memiliki dukungan pada platform berikut:

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)

Bagaimana Anda bisa mendapatkan panggilan dukungan selimut untuk 14,04 ketika masalah ini jelas sangat lazim. Docker jelas harus memberikan dukungan selimut untuk kernel tertentu pada distribusi tertentu.

Saya menggunakan CentOS dan dan peningkatan kernel tampaknya telah memperbaiki masalah penggunaan mapper run away.

Terlepas dari itu, terima kasih atas pekerjaan Anda @snitm.

Bagi mereka yang mengalami masalah ini di Ubuntu, pastikan Anda membersihkan gambar / kontainer buruh pelabuhan lama dengan tepat. Saya menemukan bahwa skrip pembersihan saya tidak berjalan seperti yang saya pikirkan, dan itulah mengapa menggunakan begitu banyak ruang.

`` #! / bin / bash

Hapus semua kontainer

buruh pelabuhan rm $ (buruh pelabuhan ps -a -q)

Hapus semua gambar

buruh pelabuhan rmi $ (gambar buruh pelabuhan -q)
``

@TylerMills perhatikan bahwa docker rm _not_ akan menghapus volume yang dibuat oleh kontainer. Jika kontainer Anda menggunakan volume, Anda harus menggunakan docker rm -v untuk meminta pekerja pelabuhan menghapus volume juga.

@snitm Kami baru saja mendapat sedikit tentang ini juga (menggunakan Ubuntu 14.04). Meskipun ini mungkin bukan kesalahan Docker secara khusus, mereka harus memiliki minat yang kuat untuk memperbaikinya karena ini mencerminkan keseluruhan pengalaman yang buruk.

Perhatikan juga saya mengalami masalah ini dan inilah yang saya lakukan untuk memperbaikinya:

Namun dalam kasus saya, karena perangkat yang / var dipasang mencapai penggunaan 100%, satu-satunya cara untuk menghentikan host dari memasuki kepanikan kernel adalah dengan mematikan proses buruh pelabuhan secara langsung (yaitu mengeluarkan perintah buruh pelabuhan akan membuat panik).

Kemudian secara manual matikan proses apa pun menggunakan devicemapper mounts menggunakan perintah ini:

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

maka saya dapat meng-umount mount devicemapper apa pun menggunakan:

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

langkah-langkah itu melepaskan semua deskriptor file yang memungkinkan saya untuk mengklaim kembali ruang / menghapus file apa pun ..

Pada titik itu dalam kasus saya, lebih masuk akal untuk memindahkan direktori / var / lib / docker ke mount dengan lebih banyak ruang dan mengkonfigurasi daemon docker untuk menggunakan direktori home yang berbeda menggunakan argumen -g

terima kasih kepada Alexander Larsson melalui Adam Miller

Mengikuti komentar @dekz , mungkin ide yang bagus jika panduan instalasi tidak menginstruksikan pengguna bahwa versi kernel tanpa perbaikan ini dapat diterima seperti yang dilakukan di sini: https://docs.docker.com/installation/ubuntulinux/

Terima kasih @JohnMorales. Sedikit peringatan tentang ini dari Docker akan menjadi ide bagus.

+1

+1

Kami baru-baru ini mendapat sedikit dengan menjalankan Ubuntu 14.04.2 LTS (3.16.0-30-generik) ini dan masih berebut untuk menemukan solusi. Sepertinya beralih ke CentOS 6.6 (yang seharusnya memiliki perbaikan kernel) atau memasang volume yang memiliki disk lebih besar adalah satu-satunya solusi.

Adakah yang menjalankan Ubuntu menemukan solusi yang dapat diterima?

Saya setuju - Docker harus mengatasi dan mengatasi masalah ini - ini adalah bug serius yang membutuhkan dokumentasi dan pesan peringatan, sehingga lebih banyak orang tidak secara naif jatuh ke dalam perangkap yang sama.

Saya setuju dengan @natea
Saya menghadapi masalah yang sama dengan redhat 6.5 dan ini menimbulkan tanda tanya besar jika buruh pelabuhan siap produksi dan kami mulai mencari alternatif.
Saya bahkan tidak keberatan mendapatkan solusi manual untuk menyelesaikan masalah, tetapi saat ini, saya tidak mengetahui solusi yang memungkinkan.

@sagiegurarie perhatikan bahwa kami mengubah persyaratan untuk CentOS menjadi 6.6 karena berbagai masalah dengan 6.5 (dan kernel terkait). Persyaratan ini mungkin belum ada di situs web dokumen langsung, tetapi akan ada pada rilis berikutnya, mungkin sebelum itu.

jadi masalah # 11643 jawaban tidak relevan? itu artinya kita tidak bisa menggunakan redhat 6.5?

@natea @sagiegurari Apa yang berhasil untuk kami adalah manual "perbaikan" yang disarankan oleh @TylerMills

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

Kelemahannya, tentu saja, Anda harus menarik kembali semua gambar dan menjalankan container lagi.

@bkeroackdsc Saya ingat saya menghapus semua container dan gambar sebelumnya juga dan itu tidak menyelesaikannya, tetapi saya akan mencobanya lagi.

Halo! Saya ingin tahu apakah masalah ini masih ada di ubuntu-15.04. Yang sekarang ada di kernel linux-3.19. Terimakasih banyak.

jika Anda menggunakan ubuntu-15.05 dengan kernel itu mengapa tidak menggunakan overlay, itu caranya
lebih baik dari devicemapper

Pada Kamis, 7 Mei 2015 pukul 11:26, Dreamcat4 [email protected] menulis:

Halo! Saya ingin tahu apakah masalah ini masih ada di ubuntu-15.04.
Yang sekarang ada di kernel linux-3.19. Terimakasih banyak.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99968299.

@jelle Oh

Ya saya menggunakan overlay :) kami berharap untuk menaikkan daftar di 1,7 hilang dari kami
gunakan dan menyukainya

Pada hari Kamis, 7 Mei 2015, Dreamcat4 [email protected] menulis:

@jfrazelle https://github.com/jfrazelle Oh benar. Apa rasanya? Melakukan
Anda menggunakan overlay? Saya telah mengasumsikan (sampai sekarang) itu
dukungan overlay masih eksperimental pada 3.19 kernel.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99982543.

@sagiegurari Mengapa Anda tetap menggunakan 6.5? Ada sejumlah pembaruan dan perbaikan yang Anda lewatkan dengan TIDAK pergi ke 6.6, termasuk CVE yang layak berita dengan nama.

@jrin karena itu bukan keputusan saya :)
bagaimanapun saya mencoba untuk memeriksa dengan semua tim untuk melihat apakah redhat 7 akan baik-baik saja untuk produksi.

Ini sepertinya masih menjadi masalah di CentOS7 (3.10.0-123.el7.x86_64). Saya menyiapkan kotak CentOS baru dan menginstal docker v1.6.0. File data devicemapper tidak pernah berkurang ukurannya setelah sudo docker rmi. Saya sedang mencari kotak CentOS6.6 untuk mencobanya.

v1.6.0 di Ubuntu 14.04 tampaknya memiliki efek positif (lebih dari v1.5.0)

sepertinya juga berfungsi dengan baik pada centos 7 yang menurut saya juga bisa dikatakan untuk redhat 7
tetapi redhat 6.5 tidak, dan saya sarankan untuk menyatakannya di dokumen.

Ini harus bekerja di buruh pelabuhan upstream terbaru. Dan komentar terakhir dari @sagiegurari sepertinya menyiratkan hal itu. (bekerja pada centos 7).

Jika itu masalahnya, kita harus menutup bug ini.

Jadi apakah masalah ini masih terjadi dengan buruh pelabuhan terbaru? Jika tidak, mari kita tutup.

baiklah .... menjalankan lebih banyak tes tampaknya memberikan hasil yang tidak pasti.
katakanlah itu jauh lebih baik, tetapi mungkin masih bocor, hanya saja jauh lebih lambat.
Saya akan menjalankan lebih banyak pemeriksaan untuk mengonfirmasi.

@bayu_joo

Dapatkah Anda memberi saya beberapa detail lebih lanjut tentang masalah yang Anda hadapi dan juga lingkungan Anda. Judul masalah mengatakan bahwa ruang tidak diklaim kembali setelah gambar / kontainer dihapus, dan pekerja galangan upstream terbaru seharusnya tidak memiliki masalah seperti itu.

Bisakah Anda mengambil buruh pelabuhan hulu, membangun biner dinamis, membuat kumpulan tipis baru (di direktori / var / lib / buruh pelabuhan /) baru, menarik gambar, menghapusnya dan melihat info buruh pelabuhan dan melihat apakah ruang telah dibebaskan atau tidak.

Saya akan menjalankan lebih banyak tes semoga minggu depan untuk memberikan info yang lebih tepat.

Saya akui saya melihatnya di mesin build kami di mana kami membuat dan menghapus banyak gambar (selama pembuatan itu sendiri) + menjalankan docker registry 2.0 (di mana kami selalu mendorong gambar yang berbeda dengan tag 'terbaru') + menjalankan beberapa kontainer ke melakukan pengujian awal bahwa semuanya bekerja dengan baik (pengujian sebenarnya tidak seharusnya berjalan di mesin itu, tetapi kami dalam tahap awal jadi kami membuat / menghentikan / rm banyak kontainer).

gambar kami sangat besar, terkadang saya melihat ukuran virtual lebih dari 2gb, jadi jika ada masalah, itu menunjukkan dirinya lebih cepat daripada dengan gambar biasa yang biasanya sekitar 400mg.

bagaimanapun, saya akan mencoba menjalankan beberapa tes untuk melihat perilaku dan memberikan rincian lebih lanjut minggu depan.

Menggunakan Docker versi 1.6.0, build 4749651 / 1.6.0 di kernel Linux 3.14.35-28.38.amzn1.x86_64

Menghapus gambar mengurangi ruang disk yang diklaim oleh buruh pelabuhan.

@tokopedia

Bisakah kita menutup masalah ini Saya tidak berpikir di buruh pelabuhan terbaru kita memiliki masalah untuk merebut kembali gambar / ruang kontainer dari file oop. Jika sesuatu yang spesifik muncul, seseorang dapat membuka masalah baru dengan detail spesifik.

@rhvgoyal Saya tidak melihat alasan untuk terburu-buru dan menutup masalah ini setelah begitu banyak orang mengeluh tentang begitu banyak platform / versi.

@bayu_joo

Saya tidak tahu apa yang kami peroleh dengan membiarkan masalah tetap terbuka. Saya tahu itu diperbaiki di hulu. Ada begitu banyak masalah yang terbuka. Orang-orang menggunakannya sebagai dasbor untuk mencatat pengamatan.

Saya merasa bahwa membiarkan masalah tetap terbuka masuk akal hanya jika ada masalah nyata yang dapat direkonstruksi. Jika tidak, daftar masalah ini akan terus bertambah dan sulit untuk mencari tahu mana yang harus difokuskan.

Tidak ada yang menghentikan Anda untuk menambahkan lebih banyak data ke masalah ini setelah Anda memilikinya.

@rhvgoyal, tag apa yang Anda

@rhvgoyal Ucapkan komit terbaru. Saya baru saja mengkloning pohon git terbaru dan mengujinya. Apakah itu penting?

Begitu banyak masalah yang dilaporkan pada rilis buruh pelabuhan lama dan kernel lama. Saya pikir langkah pertama harus melihat apakah masalah yang sama terlihat pada buruh pelabuhan terbaru dan kernerl yang relatif lebih baru. Itu memberi kami gambaran apakah itu masih menjadi masalah atau sesuatu yang tidak diperbaiki di versi yang lebih lama.

Ketika seseorang kembali dan membacanya di masa depan, ya. Saya ingin tahu versi apa itu telah diperbaiki.

Kami mengeluarkan disc dalam kasus perangkat loopback. Sebenarnya itu sudah lama dilakukan. Saya pikir 1,6 harus memilikinya.

@stanislavb diuji dengan 1.6 dan itu berhasil untuknya.

Jika Anda merujuk ke komentar pertama saya dalam masalah ini, Anda akan melihat bahwa saya juga mencoba dengan v1.6.0 di centos7 dan masih mengalami masalah.

@alex_alex

Oke, apakah Anda dapat memperbanyaknya? Jenis kumpulan tipis apa yang Anda gunakan (di atas perangkat loop?). Apakah Anda me-restart buruh pelabuhan atau ini terjadi pertama kali Anda memulai buruh pelabuhan?

Dalam beberapa kasus mungkin terjadi bahwa pekerja galangan menggunakan perangkat loop dan kemudian pekerja galangan di-restart, dapat terjadi bahwa kumpulan tidak dimatikan karena beberapa perangkat sibuk di suatu tempat. Setelah restart buruh pelabuhan
menemukan kumpulan sudah ada di sana dan tidak memiliki pengetahuan bahwa perangkat loopback sedang digunakan dan tidak mengeluarkan membuang. Saya ingin tahu apakah Anda berlari ke situasi itu?

CentOS 7

Docker versi 1.6.2.el7, build c3ca5bb / 1.6.2

Sebelum pembersihan gambar

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

Setelah beberapa buruh pelabuhan 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% /

@alex_alex

Ok, baru saja saya mem-boot image centos7 dan mencoba docker 1.6 dan saya tidak melihat masalahnya. Berikut langkah-langkahnya.

[ root @ centos7-generic ~] # versi buruh pelabuhan
Versi klien: 1.6.0
Versi API Klien: 1.18
Go versi (klien): go1.4.2
Git commit (klien): 8aae715 / 1.6.0
OS / Arch (klien): linux / amd64
Versi server: 1.6.0
Versi API Server: 1.18
Go versi (server): go1.4.2
Git commit (server): 8aae715 / 1.6.0
OS / Arch (server): linux / amd64

Sudah ada satu gambar yang diimpor.

[ root @ centos7-generic ~] # gambar buruh pelabuhan
REPOSITORY TAG IMAGE ID BUAT UKURAN VIRTUAL
docker.io/fedora ded7cd95e059 terbaru 2 minggu lalu 186.5 MB

Berikut adalah output dari info buruh pelabuhan.

root @ centos7-generic ~] # info buruh pelabuhan
Wadah: 0
Gambar: 2
Storage Driver: devicemapper
Nama Kolam Renang: docker-253: 1-50331788-pool
Ukuran Blok Kolam Renang: 65,54 kB
Sistem File Dukungan: xfs
File data: / dev / loop0
File metadata: / dev / loop1
Ruang Data Terpakai: 525,5 MB
Total Ruang Data: 107,4 GB
Ruang Data Tersedia: 20 GB
Metadata Space Terpakai: 892,9 kB
Total Ruang Metadata: 2.147 GB
Ruang Metadata Tersedia: 2,147 GB
Udev Sync Didukung: true
File loop data: / var / lib / docker / devicemapper / devicemapper / data
File loop metadata: / var / lib / docker / devicemapper / devicemapper / metadata
Versi Perpustakaan: 1.02.93-RHEL7 (2015-01-28)
Driver Eksekusi: native-0.2
Versi Kernel: 3.10.0-229.el7.x86_64
Sistem Operasi: CentOS Linux 7 (Core)
CPU: 2

[ root @ centos7-generic ~] # buruh pelabuhan rmi fedora
Untagged: fedora: terbaru
Dihapus: ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4
Dihapus: 48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731

[ root @ centos7-generic ~] # info buruh pelabuhan
Wadah: 0
Gambar: 0
Storage Driver: devicemapper
Nama Kolam Renang: docker-253: 1-50331788-pool
Ukuran Blok Kolam Renang: 65,54 kB
Sistem File Dukungan: xfs
File data: / dev / loop0
File metadata: / dev / loop1
Ruang Data Terpakai: 307,2 MB
Total Ruang Data: 107,4 GB
Ruang Data Tersedia: 20,22 GB
Metadata Space Terpakai: 733,2 kB
Total Ruang Metadata: 2.147 GB
Ruang Metadata Tersedia: 2,147 GB
Udev Sync Didukung: true
File loop data: / var / lib / docker / devicemapper / devicemapper / data
File loop metadata: / var / lib / docker / devicemapper / devicemapper / metadata
Versi Perpustakaan: 1.02.93-RHEL7 (2015-01-28)
Driver Eksekusi: native-0.2
Versi Kernel: 3.10.0-229.el7.x86_64
Sistem Operasi: CentOS Linux 7 (Core)
CPU: 2

Perhatikan Penggunaan data turun dari 525MB menjadi 307MB. Jadi menghapus gambar membuat saya mendapatkan ruang kembali.

Oke, saya lupa menempelkan ukuran file loop sebelum dan sesudah operasi. ini dia.

• Sebelum penarikan gambar.
  $ cd / var / lib / docker / devicemapper / devicemapper
  $ du -h data
  293 juta data
• Setelah gambar tarik
  [ root @ centos7-generic devicemapper ] # du -h data
  499 juta data
• Setelah penghapusan gambar
  [ root @ centos7-generic devicemapper ] # du -h data
  293 juta data

Jadi file loop saya benar-benar menyusut setelah penghapusan gambar. Saya pikir itulah yang Anda keluhkan.

@tokopedia

Apakah Anda menggunakan file loop? Mereka tidak terlihat di info buruh pelabuhan Anda. Saya pikir Anda mengalami masalah yang sama di mana ketika buruh pelabuhan memulai kolam sudah ada.

Dapatkah Anda memeriksa ukuran file backing loop (/ var / lib / docker / devicemapper / devicemapper / data) dan memastikan bahwa file tersebut menyusut setelah penghapusan gambar. (du -h).

@bayu_joo
CentOS 7, Docker versi 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

@tokopedia

Ok, Jadi ukuran perangkat loop memang turun.

Juga saya verifikasi dari kode. Kami akan mengeluarkan membuang bahkan jika setelah restart buruh pelabuhan menemukan kolam tipis sudah ada.

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

Sesuai kode di atas, discards dinonaktifkan hanya jika pengguna baik lewat perangkat blok data atau kumpulan tipis. Mengingat kami juga tidak lolos, pembuangan masih aktif. Itulah mengapa ini berhasil untuk Anda.

@alexDrinkwater Sekarang kita memiliki dua titik data yang diperbaiki di 1.6. Apakah Anda masih memiliki kekhawatiran untuk menutup masalah ini.

CentOS 6.6.0

Docker versi 1.5.0, build a8a31ef / 1.5.0

Sebelum pembersihan gambar

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

Ukuran file data diperiksa pada 1929 gambar yang tersisa

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

Setelah beberapa buruh pelabuhan 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, bahkan di 1.5 itu berhasil.

Saya menguji ini di mesin baru.

Docker versi 1.6.0, build 8aae715 / 1.6.0

Sebelum menarik:

/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

setelah tarik:

/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

hapus gambar:

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

setelah hapus:

/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

Beri tahu saya jika Anda memiliki detail lebih lanjut tentang mesin atau versi saya dll.

@alex_alex

Sepertinya Anda memasang perangkat terpisah di / var. Apa sistem file pada perangkat itu dan apa saja opsi pemasangannya?

Anda juga dapat memberi saya pengikut.

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

Bisakah Anda mencoba kasus sederhana menyimpan / var pada root itu sendiri dengan sistem file xfs. Mencoba mempersempit masalahnya sedikit.

@alex_alex

Saya memasang disk lain dengan partisi ext4 di / var / lib / docker sehingga file dukungan loopback ada di ext4 (bukan xfs) dan masih berfungsi untuk saya.

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

Benar-benar tidak yakin apa yang spesial tentang penyiapan Anda.

Untuk lebih spesifik,

• Sebelum menarik
  / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / buruh pelabuhan
• Setelah gambar tarik
  / dev / vdb1 9.8G 544M 8.7G 6% / var / lib / buruh pelabuhan
• Setelah gambar dihapus
  / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / buruh pelabuhan

@alex_alex

Perbedaan utama lainnya antara pengaturan Anda dan pengaturan saya adalah versi kernel. Saya menggunakan "3.10.0-229.el7.x86_64" sementara Anda tampaknya menggunakan "3.10.0-123.el7.x86_64". Bisakah Anda mengupgrade kernel Anda dan mencobanya.

Terima kasih atas bantuannya @rhvgoyal. Saya tidak akan dapat memperbarui kernel hari ini. Namun berikut adalah pengaturan yang Anda minta:

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

Saya tidak memiliki opsi penyimpanan khusus yang dikonfigurasi.

Menemukannya. Saya pikir itu ada hubungannya dengan sistem file ext3. Saya bisa melihat masalahnya juga. Coba sistem file yang berbeda, katakan ext4 atau xfs dan Anda tidak akan menghadapi masalah.

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

• Sebelum gambar tarik
  [ root @ centos7-generic-2 devicemapper] # du -h data
  293 juta data
• Setelah gambar tarik
  [ root @ centos7-generic-2 devicemapper] # du -h data
  501 juta data
• Setelah penghapusan gambar
  [ root @ centos7-generic-2 devicemapper] # du -h data
  501 juta data

Jadi untuk beberapa alasan jika file loopback ada di filesystem ext3, itu tidak berfungsi. Mungkin ext3 sudah cukup tua sehingga loop discards tidak berfungsi.

Terima kasih, segera setelah saya melihat filesystem-nya adalah ext3, saya pikir mungkin itu saja. Saya kira jika Anda dapat mereproduksi masalah pada ext3 maka kami dapat menyebut masalah ini ditutup. Ini akan menjadi referensi yang baik untuk orang lain.

Untuk referensi, contoh kerja saya adalah Docker 1.6.2 pada filesystem xfs dan Docker 1.6.0 dan 1.5.0 pada ext4.

@tokopedia

Bisakah kita menutup ini. Pengambilan kembali ruang bekerja dengan baik pada xfs dan ext4. ext3 tampaknya terlalu tua untuk mendukungnya.

@rhvgoyal @vbatts IIRC, ada pemeriksaan kompatibilitas yang memeriksa sistem file yang mendasarinya. Mungkin kita harus menambahkan cek untuk ext3 jika itu masalahnya?

edit:
sebagai referensi; daemon / graphdriver / overlay / overlay.go # L115

Driver loop menggunakan fallocate () untuk membuat lubang di file ketika discard masuk. Halaman manual Linux fallocate () memverifikasi bahwa itu tidak didukung pada ext3.

/ *
Tidak semua filesystem mendukung FALLOC_FL_PUNCH_HOLE; jika sistem file tidak mendukung operasi, kesalahan akan muncul. Operasi ini didukung setidaknya pada sistem file berikut:
* XFS (sejak Linux 2.6.38)
* ext4 (sejak Linux 3.0)
* Btrfs (sejak Linux 3.7)
* tmpfs (sejak Linux 3.5)
* /

@tokopedia

Jika seseorang ingin menjalankan buruh pelabuhan di ext3, saya rasa kita harus mengizinkannya. Hanya saja mereka tidak akan mendapatkan dukungan discard maka ukuran file loop tidak akan menyusut ketika image / container dihapus.

@rhvgoyal bagaimana kalau menampilkan ini di docker info ? Mirip dengan output Udev Sync Supported .

@tokopedia

Kami sudah memiliki entri di info buruh pelabuhan "Backing filesystem". Saya tidak yakin mengapa ia mengatakan extfs bukannya tepat tentang ext2 / ext3 / ext4.

Mungkin peringatan pada waktu startup di log harus dilakukan di sini. Sesuatu yang mirip dengan peringatan tentang menggunakan perangkat loop untuk kumpulan tipis.

@tokopedia

Dan saya pikir kita harus melakukannya hanya jika banyak orang terkena dampaknya. Jika tidak, maka kita hanya membuat lebih banyak pekerjaan dan kode dan itu mungkin tidak sepadan.

struct syscall.Statfs_t , dengan field Type pada ext2, ext3, dan ext4 semuanya mengembalikan 0xef53 , dan itulah yang kami gunakan untuk mendeteksi keajaiban sistem file.

struct syscall.Statfs_t, dengan kolom Type pada ext2, ext3, dan ext4 semuanya mengembalikan 0xef53, dan itulah yang kami gunakan untuk mendeteksi keajaiban sistem file.

Kekecewaan. Akan lebih baik jika memiliki informasi tersebut untuk mempermudah mengidentifikasi masalah yang dilaporkan.

Saya kira, kita harus menutup ini saja?

ditutup karena ini adalah masalah dengan ext3 yang sudah ketinggalan zaman. Harap gunakan ext4 atau xfs

menurut Anda apakah ini bisa didokumentasikan dengan lebih baik di dokumentasi utama Docker?

Apakah masalahnya ada pada sistem file atau tidak, lihat seberapa banyak kebingungan yang ditimbulkannya pada dua masalah baru-baru ini.

Terima kasih.

mengingat kembali masalah # 9786

@ dbabits ya, saya pikir menyebutkan bahwa ext3 memiliki beberapa masalah yang layak disebutkan di dokumen. Belum ada ide tentang lokasi yang tepat.

Memiliki masalah yang sama / mirip dengan XFS.
Sebelumnya ada di kernel "3.10.0-123.el7.x86_64", tetapi sekarang diperbarui di "3.10.0-229.el7.x86_64".

Semuanya dihapus (kontainer, gambar) tetapi data masih berisi 100GB.
Ada ide, tolong?

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

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

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

[ root @ docker0101 ~] # buruh pelabuhan ps -a
CONTAINER ID GAMBAR PERINTAH NAMA PELABUHAN STATUS YANG DIBUAT

[ root @ docker0101 ~] # gambar buruh pelabuhan -a
REPOSITORY TAG IMAGE ID BUAT UKURAN VIRTUAL

[ root @ docker0101 ~] # info buruh pelabuhan
Wadah: 0
Gambar: 0
Storage Driver: devicemapper
Nama Kolam Renang: docker-253: 0-268599424-pool
Ukuran Blok Kolam Renang: 65,54 kB
Sistem File Dukungan: xfs
File data: / dev / loop0
File metadata: / dev / loop1
Ruang Data Terpakai: 85,61 GB
Total Ruang Data: 107,4 GB
Ruang Data Tersedia: 40.91 MB
Ruang Metadata Terpakai: 211,4 MB
Total Ruang Metadata: 2.147 GB
Ruang Metadata Tersedia: 40,91 MB
Udev Sync Didukung: true
File loop data: / data / docker / devicemapper / devicemapper / data
File loop metadata: / data / docker / devicemapper / devicemapper / metadata
Versi Perpustakaan: 1.02.93-RHEL7 (2015-01-28)
Driver Eksekusi: native-0.2
Versi Kernel: 3.10.0-229.7.2.el7.x86_64
Sistem Operasi: CentOS Linux 7 (Core)
CPU: 4
Memori Total: 11,58 GiB
Nama: docker0101

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

[ root @ docker0101 ~] # status dmsetup
vg1-lvol0: 0 167772160 linier
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 buruh pelabuhan
Nama: buruh pelabuhan
Versi: 1.6.2.0
Rilis: 14.el7.centos
Arsitektur: x86_64
Tanggal Penginstalan: Jum 17 Jul 2015 09:19:54 AM CEST
Grup: Tidak ditentukan
Ukuran: 33825026
Lisensi: ASL 2.0
Tanda tangan: RSA / SHA256, Rabu 24 Jun 2015 05:43:12 AM CEST, ID Kunci 24c6a8a7f4a80eb5
Sumber RPM: docker-1.6.2-14.el7.centos.src.rpm
Tanggal Dibangun: Rab 24 Jun 2015 03:52:32 AM CEST
Bangun Host: worker1.bsys.centos.org

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

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

@tomlux Mode loopback peta perangkat yang Anda gunakan sebagian besar dimaksudkan sebagai cara untuk dengan mudah bermain-main dengan buruh pelabuhan. untuk pekerjaan serius, loopback akan menjadi lebih lambat, dan memiliki beberapa batasan. Saya sangat merekomendasikan membaca http://www.projectatomic.io/docs/docker-storage-recommendation/

Anda akan mendapatkan kinerja yang lebih baik, dan tidak akan mencapai hal-hal seperti ini, dengan asumsi Anda telah menerapkan semua pembaruan sistem.

@tokopedia

dapatkah Anda menambahkan "-s" ke ls. Itu akan memberi Anda blok aktual yang dialokasikan ke file data dan metadata. Sekarang ini menunjukkan ukuran file yang jelas.

keluaran info buruh pelabuhan menarik meskipun. Tampaknya menunjukkan penggunaan yang tinggi.

@tokopedia

Jadi ukuran sebenarnya dari data dan file metadata terlihat kecil. Anda bisa menggunakan "ls -alsh" agar ukuran lebih mudah dibaca.

Jadi ukuran file data sepertinya sekitar 79MB dan ukuran file metadata sekitar 202KB.

Saya pikir statistik kumpulan tipis entah bagaimana tentang jumlah blok yang digunakan tidak terlihat benar. Apakah boot ulang mesin memperbaiki masalah?

Saya melakukan reboot setelah pembaruan kernel tanpa hasil.

Ok, jadi file loop berukuran besar dan pool mengira itu memiliki banyak blok yang digunakan. Jadi ada sesuatu yang menggunakan blok itu. Dapatkah Anda memberi saya hasil.

• buruh pelabuhan ps -a
• gambar buruh pelabuhan
• ls / var / lib / dokcer / devicemapper / metadata / | wc -l
• shutdown buruh pelabuhan dan jalankan mengikuti.
  thin_dump / var / lib / docker / devicemapper / devicemapper / metadata | grep "device dev_id" | wc -l

Ini akan memberi tahu berapa banyak perangkat tipis yang ada di kolam.

Hmm,
sekarang kami memiliki wadah MATI tetapi tidak ada gambar.
Apakah sudah reboot.

Sepertinya ada yang salah dengan devicemapper.
Saya tidak ingin mengirim spam untuk masalah ini.
Saya juga bisa "rm -f / var / lib / docker" dan membangun kembali kontainer saya. Semuanya sudah diatur.

lakukan "dmsetup status"

Sepertinya kolam dalam kondisi buruk dan kemungkinan besar perlu diperbaiki.

Hai,

Saya sepertinya memiliki masalah yang sama di Ubuntu 14.04. Namun penyebab dimana volume yang tidak diinginkan (cf. blog http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/). Menjalankan perintah

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

melepaskan banyak ruang disk.

Ini tidak diperbaiki dengan cara yang berarti. Pada instalasi Ubuntu 14.04.x ​​yang sepenuhnya up-to-date (rilis LTS terbaru) dan dengan versi terbaru Docker (diinstal melalui $ wget -qO- https://get.docker.com/ | sh ), Docker akan terus membocorkan ruang tanpa cara yang mudah untuk mengklaim kembali. docker stop $(docker ps -q) && docker rm $(docker ps -q -a) && docker rmi $(docker images -q) hanya merilis sedikit ruang.

Satu-satunya cara untuk mendapatkan kembali semua ruang adalah dengan peretasan berikut:

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

Yang kemudian membutuhkan penarikan kembali gambar yang mungkin Anda butuhkan.

@bkeroackdsc mungkinkah ruang itu juga terkait dengan volume "yatim piatu"?

Saya setuju dengan @bkeroackdsc ini tidak terpecahkan.
Saya bertanya kepada @rhvgoyal mengapa dia sangat ingin menutup kasus ini.
pada akhirnya, saya turun dari buruh pelabuhan secara khusus karena masalah ini.
itu membunuh produk ini.

yatim piatu atau tidak yatim piatu, tidak ada cara yang baik, mudah, untuk membersihkan ruang.
perlu ada opsi cli buruh pelabuhan untuk pembersihan, opsi cli laporan status yang baik dan juga semacam pemantauan untuk ruang disk karena masalah ini terjadi pada terlalu banyak orang di banyak platform.

@bkeroackdsc @sagiegurari

Alasan saya bertanya adalah bahwa volume yatim piatu tidak terkait dengan masalah ini,
tidak terkait dengan devicemapper.

Volume orphaned bukanlah bug , tetapi kesalahpahaman bahwa volume didefinisikan
untuk penampung secara otomatis dihapus saat penampung dihapus.
Ini _bukan_ kasusnya (dan menurut desain), karena volume dapat berisi data
yang akan tetap ada setelah penampung dihapus.

_Untuk menghapus volume bersama dengan container_, gunakan docker rm -v [mycontainer] .
Fungsi manajemen volume akan ditambahkan (lihat https://github.com/docker/docker/pull/14242 dan https://github.com/docker/docker/issues/8363),
dan akan memungkinkan Anda untuk mengelola volume "yatim piatu".

Ukuran tumbuh /var/lib/docker tidak harus menjadi indikasi
peta perangkat tersebut membocorkan data, karena bertambahnya ukuran direktori tersebut
bisa juga merupakan hasil dari volume (yatim piatu) yang belum dibersihkan
oleh pengguna (buruh pelabuhan menyimpan semua datanya di jalur itu).

Saya sangat berharap 2 item itu akan memberikan kemampuan yang dibutuhkan.
Saya mengerti item kedua, tetapi yang pertama (# 14242), tidak menjelaskan di atas tentang apa itu selain itu adalah api volume (artinya, tidak yakin kemampuan apa yang diberikannya).

@sagiegurari itu bagian dari persyaratan untuk menerapkan manajemen volume gambar (ada beberapa masalah PR terbuka lainnya). Tujuan akhirnya adalah membuat volume menjadi warga kelas satu di Docker, yang dapat dibuat / dihapus / dikelola terpisah dari kontainer yang menggunakannya.

@swachter Terima kasih telah memposting solusi tersebut, saya mengklaim kembali 6GB dengan gambar yang disebutkan di atas.

kami memperbaiki masalah volume bocor dengan peretasan kotor, karena hal itu mencegah daemon buruh pelabuhan untuk memulai sebelum waktu layanan pada host buruh pelabuhan churn tinggi kami:

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

yang memperbaiki masalah tanpa menghapus gambar yang sudah di-cache sebelumnya.

Bisakah kita membahas masalah volume bocor dalam masalah terpisah. Membahasnya di sini memberi kesan bahwa ini adalah masalah pemeta perangkat sedangkan sebenarnya bukan.

@tomlux @rhvgoyal

Apakah Anda pernah sampai pada kesimpulan tentang apa yang terjadi di kotak CentOS 7? Host buruh pelabuhan saya hampir identik, dan saya mengalami masalah yang sama. Saya mengikuti sampai titik di mana @rhvgoyal meminta untuk menjalankan perintah thin_dump . Setelah itu, saya mulai menjalankan daemon buruh pelabuhan dan tidak akan mulai. Saya baru saja menghapus / var / lib / docker dan memulai ulang sejak saat itu, tetapi saya hanya ingin tahu apakah ada resolusi yang ditemukan karena saya (dan juga yang lainnya) mungkin akan mengalaminya lagi.

[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

Saya menemukan sumber masalah saya. Terlepas dari bagaimana tampilannya, itu tidak terkait dengan masalah di utas. Ini hanya berasal dari kesalahpahaman tentang cara kerja buruh pelabuhan. Semua, kontainer mati masih memegang ruang disk yang telah mereka alokasikan selama eksekusi. Saya hanya perlu menghapus semua bangkai kontainer untuk mengosongkan ruang disk. Saya ingat ini muncul di utas ini, tetapi saya pikir hanya dianggap volume yang dipasang, bukan ruang disk yang dialokasikan oleh wadah.

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

@tomlux Ini mungkin juga masalah Anda karena keluaran docker ps -a menunjukkan beberapa kontainer Dead .

docker rm tidak mengosongkan ruang disk penampung

boot2docker terbaru di OS X VirtualBox. OS X sepenuhnya ditambal.

Saya sedang membangun wadah yang gemuk (47 GB) dan ada masalah yang menunjukkan bahwa saya harus membangun kembali wadah tersebut. Jadi saya menghentikan kontainer dan melakukan docker rm. Pengecekan ulang menggunakan docker ssh'df -h', saya menemukan penggunaan disk masih 47 GB. Wadahnya memiliki 75 GB.

Jadi saya harus mematikan VM buruh pelabuhan lagi.

Bisakah kita menyelesaikan ini?

@ awolfe-silversky adalah disk-space _inside_ VM dikembalikan? Jika di luar VM, ini mungkin tidak terkait.

@ awolfe-silvers juga; apakah Anda juga menghapus _image_? melepas wadah saja mungkin tidak banyak membantu jika gambarnya masih ada

@ awolfe-silversky masalah ini adalah tentang devicemapper - dan jika Anda menggunakan docker-machine / boot2docker, maka kemungkinan besar Anda akan menjalankan aufs . Saya juga ingin tahu apakah Anda memiliki docker rmi citra besar Anda.

nilainya berjalan docker images , dan docker info untuk melihat apakah semuanya benar-benar seburuk yang Anda buat :)

(ya, jika Anda masih memiliki vm, dan gambar telah dihapus, maka kami harus membuka masalah baru dan men-debug lebih lanjut, karena Anda telah menemukan kasus sudut yang aneh)

Saya tidak menghapus gambar tersebut. Ini dari registri buruh pelabuhan internal.
Saya menggunakan skrip awk untuk mengukur gambar - total 6,9 GB.

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

Ini kotor tapi saya tahu bahwa semua ukuran gambar dalam MB.

Inilah cara saya mencoba mendiagnosis penggunaan:

 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

Saat ini saya memiliki kotak dengan 0 gambar.
docker volume ls -qf dangling=true tidak menunjukkan apa-apa.
docker volume ls menunjukkan banyak volume, yang menurut definisi, yatim piatu, karena tidak ada gambar untuk memilikinya.
docker volume rm $(docker volume ls) menunjukkan banyak pesan seperti itu:

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

Direktori pemeta perangkat memakan hingga 30 GiG.
Docker versi 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)

Selain itu, mengapa penginstalan default menggunakan opsi penyimpanan 'sangat tidak disarankan'?
Mengapa saya tidak diberitahu begitu saat instalasi?

Saya memiliki masalah yang persis sama di sini pada instans Amazon Linux EC2.

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

Pada kasus di mana saya menginstal gambar buruh pelabuhan baru secara teratur, satu-satunya solusi adalah melakukan hal berikut:

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

Saya tidak benar-benar berpikir hal seperti itu dapat diterima di lingkungan produksi

beberapa info tambahan:

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

Karena bug ini ada selama bertahun-tahun dan tampaknya belum ditutup, dapatkah Anda memasukkan dokumentasi buruh pelabuhan tentang devidemapper cara menghancurkan keamanan semua informasi buruh pelabuhan?
maksud saya, di halaman ini: https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
letakkan sesuatu seperti "Membersihkan pemeta perangkat" dan bagaimana melakukannya.

Saya akan mencoba melakukan rm -rf / var / lib / docker tetapi saya merasa tidak nyaman melakukannya. Bisakah seseorang memberi tahu saya jika aman?

Saya menggunakan gentoo linux di laptop harian saya dan saya mencoba buruh pelabuhan untuk belajar tetapi mengisi disk saya dan menginstal ulang seluruh sistem bukanlah suatu pilihan karena bukan VM dan menginstal ulang gentoo membutuhkan waktu.

Terima kasih atas kerjamu.

@mercuriete Pada mesin dev Anda, cukup uninstal docker, hapus direktori dan instal ulang. Bekerja dengan baik.

@ ir-fuel: Saya baru saja melakukannya dan sekarang saya punya ini:

$ 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

Saya menggunakan service docker start

@ ir-fuel terima kasih, itu berfungsi dengan baik. : +1:

Menginstal ulang buruh pelabuhan untuk melepaskan ruang disk adalah jawaban paling konyol yang saya temui saat mencari solusi untuk masalah ini. Tidak hanya membuang-buang waktu, bahkan tidak diperbolehkan di sebagian besar lingkungan. Ini cara yang bagus untuk mendapatkan bayaran jika Anda adalah pekerja per jam.

Saya sangat setuju. Sungguh menakjubkan bahwa produk seperti Docker terus menggerogoti ruang disk tanpa ada yang dapat Anda lakukan kecuali untuk menghapus / menginstal ulang.

Memeriksa masalah ini sekali lagi untuk melihat tidak ada yang berubah. +1

Masalah ini ditandai ditutup. Kami membutuhkan resolusi. Tidak ada solusi, tidak ada konfigurasi ulang. Apa status sebenarnya, dan apa pengaturan konfigurasi yang terlibat? Menghapus dan membuat ulang node Docker produksi tidak dapat diterima.

Dan apa alternatifnya? Bagaimana cara kita menghindari ini?

Jika ini tidak disarankan untuk menggunakan fitur - mengapa diam dan default
satu? Jika Anda tidak peduli dengan orang yang menggunakan devicemapper - saya mungkin akan baik-baik saja
dengan ini. Tetapi beri tahu pengguna tentang hal itu! Apakah Anda menyadari jumlahnya
orang sakit kepala karena 'solusi' luar biasa yang Anda tetapkan ??
Pada 23 Jun 2016 16:32, "kpande" [email protected] menulis:

solusinya adalah menghindari penggunaan driver mapper perangkat buruh pelabuhan,
sayangnya.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397, atau nonaktifkan
utasnya
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Selalu ada rkt …

Tidak ada keraguan mengapa tidak ada seorang pun dari hulu yang peduli untuk memberikan jawaban yang tepat kepada Anda.

tidak ada yang memaksa Anda untuk menggunakan Docker.

Itu seperti Oracle memberi tahu pengembang Java untuk menggunakan PHP karena bug JVM. Itu juga tidak konsisten dengan elevator pitch di sini

Tiga tahun lalu, Docker membuat teknologi kernel Linux esoterik yang disebut containerization sederhana dan dapat diakses oleh semua orang.

Saya yakin banyak orang yang bersyukur bahwa Docker lepas landas seperti itu dan itu tidak mungkin terjadi tanpa menjadi sukarelawan dari komunitas. Namun, seharusnya tidak sesulit ini untuk mengakui bahwa ia juga memiliki masalah tanpa secara implisit menghapus baris "Saya adalah kontributor hulu jadi diam dan dengarkan" setiap kali seseorang mengemukakan hal yang tidak disukai.

Tunggu. Saya memang melaporkan masalah, memberikan detail mesin dan penyiapan saya,
yang tidak wajib saya lakukan. Tidak ada devteam yang menanggapi bug saya dan orang lain
laporan dalam periode setengah tahun. Sekarang saya menyatakan fakta ini, Anda menyebut perilaku saya
bitchy? Apakah Anda bahkan open-source? Saya mencari proyek Go untuk dikerjakan, dan
itu tidak akan menjadi Docker, saya berikan itu. Apakah ini tujuan Anda?
Pada 23 Jun 2016 16:45, "gregory grey" [email protected] menulis:

Jika ini tidak disarankan untuk menggunakan fitur - mengapa diam dan default
satu? Jika Anda tidak peduli dengan orang yang menggunakan devicemapper - saya mungkin akan baik-baik saja
dengan ini. Tetapi beri tahu pengguna tentang hal itu! Apakah Anda menyadari jumlahnya
orang sakit kepala karena 'solusi' luar biasa yang Anda tetapkan ??
Pada 23 Jun 2016 16:32, "kpande" [email protected] menulis:

solusinya adalah menghindari penggunaan driver mapper perangkat buruh pelabuhan,
sayangnya.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Pertama-tama, jika Anda masih mengalami masalah ini, buka edisi baru;

Tunggu. Saya memang melaporkan masalah

Anda membalas pada edisi 3 tahun, tertutup; setelah diskusi di atas, masalah asli telah diselesaikan. Masalah Anda _mungkin_ sama, tetapi perlu lebih banyak penelitian untuk memastikan; kesalahan yang Anda laporkan menunjukkan bahwa itu mungkin benar-benar sesuatu yang lain.

Saya sangat merekomendasikan untuk membuka masalah baru, bukan mengomentari masalah yang sudah ditutup

memberikan detail mesin dan penyiapan saya, yang tidak wajib saya lakukan.

Anda tidak _ diwajibkan_, tetapi tanpa informasi apa pun untuk dilanjutkan, kemungkinan tidak akan terselesaikan. Jadi, saat melaporkan bug, harap sertakan informasi yang diminta dalam template:
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

Tidak ada devteam yang menanggapi laporan bug saya dan orang lain dalam periode setengah tahun.

Jika yang Anda maksud adalah "salah satu pengelola", harap diingat bahwa ada hampir 24.000 masalah dan PR, dan kurang dari 20 pengelola , banyak di antaranya melakukannya selain pekerjaan sehari-hari. Tidak setiap komentar akan diperhatikan, terutama jika komentar tersebut membahas masalah tertutup.

Jika ini bukan fitur yang disarankan untuk digunakan - mengapa diam dan merupakan fitur default?

Ini adalah default jika _aufs_, _btrfs_, dan _zfs_ tidak didukung, Anda dapat menemukan prioritas yang digunakan saat memilih driver; lihat daemon / graphdriver / driver_linux.go . Ini masih di atas overlay, karena sayangnya ada beberapa masalah tersisa dengan driver yang _some_ orang mungkin terpengaruh.

Memilih driver grafik secara otomatis hanya untuk "menjalankan semuanya"; driver terbaik untuk situasi _Anda_ bergantung pada kasus penggunaan _Anda. Docker tidak dapat membuat keputusan itu secara otomatis, jadi ini terserah pengguna untuk mengonfigurasi.

Jika Anda tidak peduli dengan orang yang menggunakan devicemapper - saya mungkin akan baik-baik saja dengan ini.

Membaca kembali diskusi di atas, saya melihat bahwa pengelola peta perangkat hulu telah melihat ke _multple times_ ini, mencoba membantu pengguna melaporkan masalah ini, dan menyelesaikan masalah. Masalah ini diselesaikan bagi mereka yang melaporkannya, atau dalam beberapa kasus, bergantung pada distro yang memperbarui versi peta perangkat. Saya tidak berpikir itu bisa dianggap "tidak peduli".

Selain itu, mengapa penginstalan default menggunakan opsi penyimpanan 'sangat tidak disarankan'?

Berjalan pada perangkat loop baik-baik saja untuk menjalankan buruh pelabuhan, dan saat ini satu-satunya cara untuk mengatur devicemapper secara otomatis. Untuk produksi, dan untuk mendapatkan performa yang lebih baik secara keseluruhan, gunakan direct-lvm, seperti yang dijelaskan di bagian devicemapper di panduan pengguna driver penyimpanan.

Mengapa saya tidak diberitahu begitu saat instalasi?

Itu di luar ruang lingkup untuk instalasi, sungguh. Jika Anda akan menggunakan beberapa perangkat lunak dalam produksi, masuk akal untuk berasumsi bahwa Anda sudah terbiasa dengan perangkat lunak itu, dan tahu apa yang diperlukan untuk menyiapkannya untuk kasus penggunaan Anda. Beberapa pengelola bahkan berdebat jika peringatan itu harus dikeluarkan sama sekali. Linux bukanlah OS "berpegangan tangan" (apakah distro Anda menunjukkan peringatan bahwa kehilangan data dapat terjadi jika Anda menggunakan RAID-0? Jika Anda membuka port di Firewall?)

Meskipun saya sangat enggan, untuk sekali lagi menghidupkan kembali utas kuno ini, masih belum ada nasihat yang berarti di dalamnya tentang cara mengatasi masalah ini pada mesin yang ada yang menghadapi masalah ini.

Ini adalah upaya terbaik saya di tldr; untuk seluruh utas; Saya harap ini membantu orang lain yang menemukan utas ini.

Terjadi masalah

Volume Anda memiliki jumlah ruang yang signifikan (dan terus bertambah) yaitu /var/lib/docker dan Anda menggunakan ext3.

Resolusi

Anda kurang beruntung. Tingkatkan sistem file Anda atau lihat blowing docker away di bagian bawah.

Terjadi masalah

Volume Anda memiliki jumlah ruang yang signifikan (dan terus bertambah) yaitu /var/lib/docker dan Anda _not_ menggunakan ext3 (mis. Sistem saat ini menggunakan xfs atau ext4)

Resolusi

Anda mungkin dapat memperoleh kembali ruang pada perangkat Anda menggunakan perintah buruh pelabuhan standar.

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

Jalankan perintah ini:

docker volume ls
docker ps
docker images

Jika Anda tidak memiliki apa pun yang terdaftar di semua ini, lihat blowing docker away di bagian bawah.

Jika Anda melihat gambar lama yang basi, kontainer yang tidak digunakan, dll. Anda dapat melakukan pembersihan manual dengan:

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

Ini harus merebut kembali banyak ruang kontainer yang tersembunyi di devicemapper.

Menghancurkan buruh pelabuhan

Tidak berhasil? Anda kurang beruntung.

Taruhan terbaik Anda saat ini adalah:

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

Ini akan menghancurkan semua gambar buruh pelabuhan Anda. Pastikan untuk mengekspor yang Anda inginkan agar _before_ melakukan ini.

Terakhir, harap baca https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-production; tapi saya harap ini akan membantu orang lain yang menemukan utas ini.

Jika Anda memiliki masalah dengan menggunakan saran di atas, buka tiket baru yang secara khusus membahas masalah yang Anda temui dan tautkan ke masalah ini; jangan posting disini.

rm -rf / var / lib / buruh pelabuhan

Anda juga dapat menggunakan nuke-graph-directory.sh .

Setelah menghapus file seperti yang disebutkan di atas, saya tidak dapat memulai Docker lagi:
02 Mar 04:53:40 pmdc001b dockerd [29522]: Error start daemon: error inisialisasi graphdriver: open / var / lib / docker / devicemapper / devicemapper / data: tidak ada file atau direktori seperti itu

Baru saja mengalami masalah ini di CentOS 7.3 dan tidak ingin men-debug masalah devmapper yang ada selama lebih dari 3 tahun, jadi saya mengikuti panduan DC / OS ini, membersihkan paket asli, beralih ke overlayfs dan semuanya tampak berfungsi dengan baik sekarang : https://dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/ (harus mengubah perintah ExecStart untuk docker versi 17.03 meskipun -> "dockerd --storage-driver = hamparan ")

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

(membersihkan volume, gambar, dan container tidak membantu. Menghapus item di / var / lib / docker menyebabkan masalah yang dijelaskan oleh @ gdring2 )

Menjalankan docker system prune membebaskan banyak ruang di mesin saya.

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

Ini agak ... payah.

Dalam kasus saya, saya menemukan masalah ini setelah saya mencopot pemasangan Docker dan menghapus direktori /var/lib/docker , jadi saya tidak dapat menjalankan yang setara dengan service docker stop ... service docker start .

Saya menemukan bahwa sistem saya tidak melaporkan ruang dari menghapus /var/lib/docker sebagai dibebaskan (saya memiliki ~ 14 GB duduk di tempat yang tampak seperti limbo).

Perbaikan untuk ini adalah dengan memuat ulang sistem file Anda, dalam kasus saya, saya baru saja mem-boot ulang dan ruang itu diklaim kembali.

Saya tidak percaya itu masih menjadi masalah! Ayo teman-teman, saya masih mengalami itu

@ shahaf600 versi buruh pelabuhan apa yang Anda jalankan? Lihat juga komentar saya di atas; https://github.com/moby/moby/issues/3182#issuecomment -228298975

Tanpa detail, tidak banyak yang bisa dikatakan tentang situasi Anda; kasus Anda dapat disebabkan oleh masalah yang berbeda, tetapi mengakibatkan hasil yang serupa.

baik

setelah membeli salah satu dari sampah ini dan melihat keadaan dukungan, saya mengembalikannya.

Ada masalah pertamamu @misterbigstuff ... kamu membeli sesuatu yang open source?

dan mengembalikannya