+1, मुझे इस विषय पर कुछ चर्चा सुनने में बहुत दिलचस्पी है। मेरी अब तक की रणनीति रही है

• सावधान रहें कि आप क्या बनाते / खींचते हैं
• अपने / var / lib / docker को उड़ाने के लिए तैयार रहें: neutral_face:

@AaronFriel , आप

/ cc @regilero (लिंक भी # 2276 पर)

नए सिरे से शुरू करना / 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

फिर डॉकटर के व्यस्त होने के बाद यह थोड़ा बढ़ गया:

# 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 बिजीबॉक्स _not_ फ़ाइल को बड़ा बनाता है, लेकिन डेविसमैपर पूल में जगह खाली करता है:

# 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

यदि हम छवि को फिर से डाउनलोड करते हैं तो लूपबैक फ़ाइल नहीं बढ़ती है:

# 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

तो, ऐसा लगता है कि जब हम लूपबैक डिवाइस को ब्लॉक करते हैं, तो हम लूपबैक फ़ाइल को फिर से स्पार्सिफाई करने में विफल होते हैं।

हालाँकि, अगर मैं कंटेनर fs छवि के अंदर एक फ़ाइल बनाता हूँ तो यह _does_ लूपबैक फ़ाइल में स्थान को पुनः प्राप्त करता है।
यानी मैंने बिजीबॉक्स इमेज में ऐसा किया है:

 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

इससे डेटा फ़ाइल 299M से बढ़कर 344M हो गई। लेकिन जब मैंने a_file.bin को हटा दिया (और थोड़ा इंतजार किया) तो यह 299M पर वापस आ गया।

तो, यह मेरे लिए ऐसा लगता है जैसे यह एक डेविक्मेपर बग है। यानी यह थ्रेश डिवाइस से अंतर्निहित डिवाइस की ओर फॉरवर्ड करता है, लेकिन पूल से थिनप डिवाइस को हटाते समय यह नहीं हटता।

यह एक कर्नेल मुद्दा प्रतीत हो रहा है, मैं इसे BLKDISCARD का उपयोग करके bu के आसपास काम कर रहा था, लेकिन मैं विफल रहा। कुछ विवरणों के लिए यह बग देखें: https://bugzilla.redhat.com/show_bug.cgi?id=1043527

मैंने https://github.com/alexlarsson/docker/tree/blkdiscard में अपना वर्कअराउंड डाला, लेकिन हम अभी भी शोध कर रहे हैं कि क्या हम इससे बेहतर कर सकते हैं।

इस मुद्दे पर अपस्ट्रीम डीएम टिप्पणी:
http://device-mapper.org/blog/2013/12/17/thin-provisioning-and-discard-support/

Docker 0.7.0 के साथ CentOS (2.6.32-358.23.2.el6.x86_64) पर भी यह समस्या है। पुरानी है, लेकिन समस्या उबंटू के लिए अलग नहीं है।

आर्क GNU / Linux 3.12.6-1-ARCH, डॉकर संस्करण 0.7.2 पर एक ही मुद्दा।

अभी भी सेंटोस पर 0.7.0 पर मौजूद है।

Ubuntu 12.04.3 LTS पर अभी भी 0.7.2 में मौजूद है।

बहुत सी जगह docker/devicemapper/devicemapper/data और metadata , लेकिन docker/devicemapper/mnt

यह साफ है कि मैंने सीखा है कि आप docker/devicemapper/mnt/SOME_KIND_OF_ID/rootfs में कंटेनर फ़ाइल सिस्टम देख सकते हैं

लेकिन यह साफ नहीं है कि मेरी हार्ड डिस्क लगभग पूरी तरह से खा ली गई है और केवल rmdir -r docker हिसाब से तय की जा सकती है।

मैं एक समान मुद्दा रहा हूँ, जबकि rspec- सिस्टम के लिए docker समर्थन लिख रहा हूँ। मेरे परीक्षण वीएम (डॉकटर होस्ट) में 8 जीबी ड्राइव है और बार-बार चित्र बनाने के बाद उन्हें हटाए बिना मेरी ड्राइव भर जाती है। लेकिन सभी छवियों और कंटेनरों को हटाने के बाद भी ड्राइव 100% भरा हुआ है। मुझे लगा कि यह एक आईडी -10 टी त्रुटि थी, लेकिन सिर्फ वीएम को छोड़ दिया और सभी को एक साथ नष्ट कर दिया।

Ubuntu 13.04 पर अभी भी 0.7.5 में मौजूद है।

यह मुद्दा PR # 3256 द्वारा तय किया गया है जिसे हाल ही में विलय कर दिया गया था। यह फिक्स भविष्य के रिलीज़ में शामिल किया जाएगा।

मैं अब इस मुद्दे को बंद कर रहा हूं क्योंकि फिक्स को मास्टर में विलय कर दिया गया है।

नोट: इसका न तो _ly_ तय है जब तक कि आप http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id= के साथ एक कर्नेल भी चलाते हैं।

अंतरिक्ष को हटाने के लिए चारों ओर क्या काम है। मैं rhel 6.5 का उपयोग कर रहा हूं और नई कर्नेल प्राप्त करने में कुछ समय लग सकता है।

मेरे आईफोन से भेजा गया

21 जनवरी 2014 को सुबह 6:18 बजे, अलेक्जेंडर लार्सन नोटिफिकेशन @ithub.com ने लिखा:

नोट: यह पूरी तरह से तय नहीं है, जब तक कि आप http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next.id= के साथ कर्नेल चलाते हैं।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें।

@logicminds अंतरिक्ष atm को पुनर्प्राप्त करने का कोई सुपर आसान तरीका नहीं है। तकनीकी रूप से यह लूपबैक फ़ाइलों को मैन्युअल रूप से पुन: sparsify करना संभव होना चाहिए। लेकिन इसके लिए सभी गैर-उपयोग किए जाने वाले ब्लॉकों को शून्य करने की आवश्यकता होगी या विरल क्षेत्रों का आसानी से पता लगाने के लिए कुछ किया जाएगा, जो कि पतले डिवाइस को हटाने पर नहीं किया जाता है।

@alexlarsson क्या यह OEL 6.5 को भी प्रभावित करता है? OEL 6.5 वास्तव में uek 3.8 लिनक्स कर्नेल का उपयोग करता है और चूंकि मेरे पास 2.6 से 3.8 कर्नेल पर स्विच करने के बीच का विकल्प है, इसलिए यह मेरे लिए एक सरल स्विच हो सकता है।

@logicminds मैं यह भी नहीं जानता कि क्या वह प्रतिबद्धता अभी तक अपस्ट्रीम कर्नेल में है। वह लिंक डिवाइस-मैपर ट्री से है। यह निश्चित रूप से 3.8 में नहीं है।

मैं फ्रॉस्टिम जैसा एक उपकरण बनाने पर विचार कर रहा हूं जिसका उपयोग अंतरिक्ष वापस पाने के लिए किया जा सकता है।

@alexlarsson के मुद्दे https://bugzilla.redhat.com/show_bug.cgi?id=1043527 को "अनुपयुक्त डेटा" के कारण आधिकारिक रूप से बंद कर दिया गया है। क्या इसका मतलब यह है कि पैच इसे कर्नेल में नहीं बनाएगा? क्या अब भी इसकी जरूरत है?

@vrvolle पैच जो कि

मैं अभी भी इस समस्या को docker 0.9 पर सेंटोस 6.5 के साथ डिफ़ॉल्ट 2.6.32 कर्नेल के साथ करता हूं।

मुझे समझ में नहीं आ रहा है कि आपने डिवाइस-मैपर में इस बारे में पहले क्या कहा था। क्या आप इस बात की पुष्टि कर सकते हैं कि अगर मैं अपने कर्नेल को 3.8 पर माइग्रेट करता हूं तो इस बग को हल किया जाना चाहिए?

अग्रिम में धन्यवाद।

@ निकोलस-वैन नहीं, आपको इस वचन की आवश्यकता है: https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316

यह 3.14 में है, और विभिन्न 3.xy बैकपोर्ट में हो सकता है

मैंने कुछ समय पहले एक इमेज बनाने और एक कंटेनर के भीतर चलाने के लिए डॉकटर स्थापित किया है। फिर कुछ समय बाद मैंने डॉकटर एप्लिकेशन और मुख्य फ़ोल्डर सहित सभी छवियों और कंटेनरों को साफ कर दिया।
अब मुझे एहसास हुआ कि कुल 4GB / 24GB फ्री / यूज्ड (df -h), कमांड du / -sh केवल 10GB रिपोर्ट करता है इसलिए अन्य 10Gb का हिसाब नहीं दिया जा रहा है। यह डॉक के साथ उत्पन्न अस्थायी छवियों का आकार कम है, क्या यह इस बग से संबंधित हो सकता है। मैंने सेंटोस 6.5 और डॉकटर 0.9 का उपयोग किया है।

मैंने yum के साथ docker को हटा दिया है, और dmsetup के साथ / dev / mapper / docker से devs, और rm / var / lib / docker -Rf, और अभी भी df 10gb के साथ डिस्क रिपोर्ट का उपयोग किया है जो मुझे कहीं भी मिल सकता है।

@Jacq इसकी संभावित कुछ फ़ाइल को अभी भी एक प्रक्रिया द्वारा जीवित रखा गया है जिसमें एक फ़ाइल विवरणक खुला है। आपने रिबूट किया? यह सुनिश्चित करेगा कि ऐसा न हो।

मैं लिनक्स 3.14.4-1-ARCH चलाता हूं, और 0.11.1 docker, सभी छवियों और कंटेनरों को हटा दिया।
और फ़ाइल / var / lib / docker / devicemapper / devicemapper बस चारों ओर अटक गया, लगभग 1.5GB की खपत

यहाँ से उत्पादन के बाद मैं कुछ mongodb सामान के साथ fiddling था, मुझे लगता है कि फ़ाइल का आकार कम से कम आवंटित किया जाना चाहिए क्योंकि मेरा / var इतना बड़ा भी नहीं है।

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

माफ कीजिए, क्या अब बग ठीक हो गया है? मैंने इसका सामना जेंटू में किया।

@bolasblack मैं gentoo

मैं नवीनतम gentoo- स्रोतों का उपयोग कर रहा हूं जो x86_64 के लिए 3.14.14 हैं। मैंने https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316?diff पर देखा और उस पैच को मेरे स्रोतों पर लागू किया गया है। मेरे पास डॉकर संस्करण 1.1.0 है, 79812e3 का निर्माण।

@alexlarsson इतने लंबे समय के बाद इस बंद मुद्दे पर अपना ध्यान वापस लाने के लिए धन्यवाद। ऐसा लगता है कि यह अभी भी परेशानी पैदा कर रहा है। # 4202 की स्थिति पर कोई शब्द?

यह अभी भी एक मुद्दा है! मुझे लगता है कि मैं समय के लिए AUFS का उपयोग करने के लिए वापस स्विच करने जा रहा हूं।

@daniellockard AUFS को अनाधिकृत रूप से पदावनत किया गया प्रतीत होता है: # 783 और # 4704, इसके साथ सौभाग्य।

Yikes ... वह 25GB कहां गया? ओह, उस एक फ़ाइल में .... मैं कर्नेल 3.16.2 f20 64b चला रहा हूं

'वर्कअराउंड' का लिंक टूट गया है ... यह क्या है? और क्या मेरा कर्नेल इसका समर्थन करता है ... यदि टोरवेल्स 3.14 में प्रतिबद्ध है, तो मुझे संदेह है कि फेडोरा को इसे 3.16 में देखना चाहिए, नहीं?

+1

+1

+1

+1 अभी भी उबंटू ट्रस्टी पर लग रहा है, 3.13.0-36- डोकर संस्करण 1.3.1 के साथ जेनेरिक, 4e9bfa का निर्माण

ट्रस्टी पर भी +1। क्या यह 14.10 पर जांचने योग्य है जो 3.16 का उपयोग करता है?

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

शीर्ष कमिटर्स को टैग करना क्योंकि यह हास्यास्पद है। इस बारे में एक सार्वजनिक बातचीत और डॉकर की टीम से एक प्रवेश की आवश्यकता है कि इस बग में कंटेनर या सिस्टम हो सकते हैं जो समय-समय पर टूटते हैं और इसे फिर से बनाने की आवश्यकता होती है। मैं पहले से ही कई लोगों को जानता हूं, जिन्हें हर हफ्ते या दो-दो बार अपने डॉक मेजबानों को फिर से शुरू करने जैसे पागल देवोपचार समाधानों को लागू करना पड़ा है क्योंकि उनके बिल्ड बॉट में बहुत मंथन होता है। मैंने इस मुद्दे को करीब एक साल पहले पेश किया था और वहाँ रहा है, जैसा कि मैं बता सकता हूं, कोई निश्चित समाधान नहीं बनाया गया है, और पुराने गुठली जो ओस्टेंसिक रूप से समर्थित हैं, वे नहीं हैं।

डॉकर टीम: कृपया यह निर्धारित करने के लिए अनुसंधान करें कि कौन से कर्नेल संस्करण प्रभावित हैं, क्यों, और क्या पैच समस्या को ठीक करेगा, और इसे दस्तावेज़ित करेगा। इस जानकारी को प्रकाशित करें कि आप किन कर्नल संस्करणों का समर्थन करते हैं, क्योंकि अभी इस मुद्दे पर डॉकर के उपभोक्ता इस मुद्दे पर थोड़ा-थोड़ा कर रहे हैं, जैसा कि इस तथ्य से स्पष्ट है कि मुझे अभी भी इस मुद्दे पर हर सप्ताह या दो पर ईमेल मिलते हैं। गंभीरता से, यह एक ब्रेकिंग मुद्दा है और 1.0 से पहले से यह एक दर्द बिंदु है।

जैसा कि मैं इसे देखता हूं, इस मुद्दे को संतोषजनक तरीके से ठीक करने के लिए कई संभावित विकल्प हैं जो इस मुद्दे पर मुझे मिलने वाले ईमेल को रोकते रहेंगे + 1s:

1. डिवाइस-मैपर का उपयोग किसी असमर्थित कर्नेल पर किए जाने पर उपयोगकर्ताओं को सूचित करें और उन्हें स्पेस को पुनः प्राप्त करने के लिए विस्तृत निर्देश प्रदान करें, और यदि संभव हो तो डॉकर में ऐसा करने के लिए स्वचालित रूप से एक प्रक्रिया सेट करें। मैं यह सलाह दूंगा कि इस समस्या से पीड़ित मेजबान के खिलाफ docker CLI का उपयोग करते समय इस नोटिस को भी हटा दिया जाना चाहिए, ताकि जब docker CLI से रिमोट मैनेजिंग मेजबानों को होस्ट किया जाए, तो उपयोगकर्ताओं को इस बात से अवगत कराया जाए कि कुछ होस्ट सही तरीके से स्थान प्राप्त नहीं कर सकते हैं।
2. समस्या को ठीक करें (किसी तरह)। मैं यह जानने के लिए कर्नेल विकास के बारे में पर्याप्त नहीं जानता कि यह क्या होगा, लेकिन, मेरे नौसिखिए पढ़ने के आधार पर, मैं यह सुझाव देता हूं:

ए। जैसा कि डिवाइस मैपर एक कर्नेल मॉड्यूल है, डॉकियर स्रोत के पेड़ में एक कार्यात्मक, काम करने वाला संस्करण लाएं, जैसे dm-docker

बी dm-docker पर्याप्त परिवर्तन करें कि यह डिवाइस मैपर के साथ सह-अस्तित्व में आ सके।

सी। प्रभावित प्लेटफार्मों पर, dm-docker का उपयोग करने के लिए स्थापना और डिफ़ॉल्ट पर dm-docker कर्नेल मॉड्यूल स्थापित करें।

1. प्रभावित कर्नेल संस्करणों पर एक चेतावनी शामिल करने के लिए अपने इंस्टॉलेशन डॉक्स और docker.com साइट को संशोधित करें, और सही डिवाइस-मैपर ऑपरेशन को सत्यापित करने के लिए संकुल में रनटाइम चेक जोड़ें, और यदि उपयोगकर्ता को इसकी सूचना नहीं है।

यह डॉकटर की अगली स्थिर रिलीज के लिए एक अवरुद्ध मुद्दा होना चाहिए, क्योंकि यह उस पर पंटिंग रखने और उपयोगकर्ताओं को लचर में छोड़ने के लिए सिर्फ सादा अस्वीकार्य है।

व्यक्तिगत रूप से मैं कोरओएस को डोकर के लिए केवल एक स्थिर लिनक्स डिस्ट्रो के रूप में देखता हूं (जब तक कि यह समस्या हल नहीं हो जाती)।

डॉकर टीम: मुझे पता है कि यह समस्या आपके घटक के कारण नहीं है, लेकिन कृपया, हमारे सॉफ़्टवेयर को दूसरों के लिनक्स पर भी उपयोग करने में हमारी मदद करें। यह ठीक होगा यदि आप इस मुद्दे को डॉक्यूमेंटेशन में डॉकटर की एक प्रसिद्ध सीमा के रूप में भी उल्लेख कर सकते हैं, इसलिए अन्य लोग अपना समय बर्बाद नहीं करेंगे।

धन्यवाद!
मार्टिन

+1 कुछ करने की जरूरत है।

यह अच्छा होगा अगर इस मुद्दे के लिए कुछ और अधिक स्पष्ट था (बंद) गितुब मुद्दों की सूची में खुदाई करने के लिए। वास्तव में यह पता लगाने में एक लंबा समय लगा कि यह अंतर्निहित मुद्दा था और इस मुद्दे में दृश्यता अच्छी थी।

हमारे अपस्ट्रीम डिवाइस मैपर डेवलपर्स (स्वयं और जो थॉर्नबर) के पास बिल्कुल _zero_ जागरूकता थी कि यह समस्या अभी भी लोगों के लिए एक समस्या है। एक बार जब हम इसके बारे में अवगत करा दिए गए (@ दिसंबर 2013 में हमने इसे तुरंत ठीक कर दिया और इसे उस समय _all_ स्थिर कर्नेल में शामिल करने के लिए टैग किया, तो देखें: http://git.kernel.org/linus/19fa1a6756ed9e9 ( "डीएम पतली: पहले से साझा ब्लॉक के लिए समर्थन को त्यागें")

जो थॉर्नबर को सिर्फ इस बात से अवगत कराया गया कि docker go कोड में ट्रिम-पूल को लागू किया। जब मैंने उसे बताया कि उसने एक उचित स्टैंडअलोन 'थिन_ट्रिम' टूल को लागू किया है, जो 'डिवाइस-मैपर-सस्टेन-डेटा' पैकेज के हिस्से के रूप में वितरित किया जाएगा (कम से कम फेडोरा, सेंटोस, आरएचईएल पर), देखें:
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

SO ... सभी कहा जा रहा है, जो उपयोगकर्ता कर्नेल चला रहे हैं, जिनके पास अपस्ट्रीम कमिटमेंट नहीं है 19fa1a6756ed9e9 ("dm पतली: पहले साझा किए गए ब्लॉक के लिए समर्थन को त्यागें") को कर्नेल को चलाने की जरूरत है जो बेहतर सपोर्ट करता है। मैं आसानी से स्थिर @vger.kernel.org को एक नोट भेज सकता हूँ ताकि किसी भी स्थिर गुठली को ठीक न किया जा सके। तो कृपया मुझे बताएं कि कौन सा, यदि कोई हो, स्थिर कर्नेल (ओं) में यह ठीक नहीं है।

आगे बढ़ते हुए, हम चाहते हैं कि डॉकटर समय-समय पर 'थिन_ट्रीम' को उस थिन-पूल डिवाइस के विरुद्ध ले जाए जो डॉक का उपयोग कर रही है। लेकिन जब हम डिस्ट्रोस में व्यापक रूप से उपलब्ध होते हैं, तो हम उस पुल को पार कर लेंगे।

@shabbychef @daniellockard नहीं, AUFs को पदावनत नहीं किया गया है - पहले, उन मुद्दों में से केवल एक बंद है, और पढ़ने पर, मैं https://github.com/docker/docker/issues/783#issuecomment -3873113737 का अनुमान लगा रहा हूं पढ़ने योग्य:

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 आप उपयोगकर्ताओं को यह बताने के लिए hack/check_config.sh कुछ जोड़ सकते हैं कि उनके पास यह पैच नहीं है?

@SvenDowideit दुर्भाग्य से प्रश्न में परिवर्तन एक अनियंत्रित कर्नेल में पहचाना नहीं गया है। शुरुआत के लिए 19fa1a6756ed9e9 पतले या पतले-पूल लक्ष्य के संस्करण से टकराए नहीं। लेकिन फिर भी अगर यह किया गया कि संस्करण सभी स्थिर कर्नेल में भिन्न होगा (और इसीलिए एक 'स्थिर' कमिट के भीतर संस्करण धक्कों खराब हैं .. क्योंकि यह सभी कर्नेलों के हाथ-संपादन के कारण होता है, जिसे कमिटेड बैकपोर्ट किया जाता है)।

लेकिन, जिन उपयोगकर्ताओं के पास पतले और पतले-पूल लक्ष्य संस्करण हैं = = 1.12.0 सभी को ठीक करना होगा। तो गुठली> = 3.15। उपयोगकर्ता जो चल रहे हैं, उन्हें @alexlarsson के docker.git को 0434a2ce ("devmapper: blkdiscard विकल्प जोड़ें और इसे कच्चे उपकरणों पर अक्षम करें" शामिल करना होगा)

FYI करें, 'dmsetup टार्गेट' चलाने से पतले और पतले-पूल लक्ष्य संस्करणों की सूची होगी (बशर्ते dm-thin-pool कर्नेल मॉड्यूल लोड किया गया हो)।

इस पर ध्यान देने के लिए धन्यवाद। हमने इसका उल्लेख पिछले सप्ताह रे: इनवेंट में बूथ के दोस्तों के लिए किया।

@snitm तो dmsetup targets आउटपुट को check-config आउटपुट में जोड़ा जाना चाहिए?

@snitm

क्या एक स्वचालित परीक्षण बनाना संभव होगा जो एक पतले-प्रावधान वाले डिवाइस-मैपर डिवाइस बनाएगा, उस पर कुछ ऑपरेशन करेगा जो एक अप्रकाशित कर्नेल पर मुक्त स्थान को पुनः प्राप्त करने में विफल होगा, और उसके आधार पर स्थिति कोड की रिपोर्ट करेगा?

@SvenDowideit आप किसी भी नए आक्रामक गुठली को पकड़ने से पहले उम्मीद कर रहे हैं कि वे लूपबैक के डीएम पतले प्रोविजनिंग का उपयोग करना शुरू कर देंगे?

@AaronFriel इस विशेष फिक्स पर लटकाए जाने की गुंजाइश में बेहद संकीर्ण लगता है। यह सुनिश्चित करने की तुलना में डीएम पतले-प्रोविजनिंग के एंटरप्राइज-ग्रेड परिनियोजन के लिए अधिक है (दुर्भाग्यपूर्ण वास्तविकता)। डीएम थिन प्रोविजनिंग टारगेट में 19fa1a675 ऊपर जाने के बाद से कई एरर हैंडलिंग, परफॉर्मेंस और फीचर में सुधार देखा गया है। उत्पादन में डीएम की पतली व्यवस्था को लागू करते समय सभी महत्वपूर्ण हैं।

तो एक कदम पीछे हटते हुए, मैं एक ऐसी कंपनी के लिए काम करने का आनंद लेने में सक्षम हो गया जो समझती है कि स्तरित उत्पादों को सभी अंतर्निहित परतों के साथ संगीत कार्यक्रम में विकसित करने की आवश्यकता है। और मुझे डीओ के पतले प्रावधान का समर्थन करने में बहुत कम दिलचस्पी है जो एन मनमानी कर्नेल को डॉकटर के साथ जोड़ा जा रहा है।

और मैं _strongly_ का मानना ​​है कि किसी को भी डीएम पतले प्रोविजनिंग का उपयोग लूपबैक उपकरणों के साथ समर्थन उपकरणों के रूप में नहीं करना चाहिए। यह एक पूर्ण हैक था जिसे "उत्पादन में कैसा दिखता है" के लिए उचित संयम या चिंता के बिना डॉक में विलय हो गया।

मैंने महसूस किया है कि डीएम पतली प्रोविजनिंग पर डॉकटर की उचित तैनाती के लिए एंटरप्राइज़-ओरिएंटेड मैनेजमेंट फीचर्स की आवश्यकता होती है जो lvm2- आधारित थिन-प्रोविज़न कॉन्फ़िगरेशन प्रदान करता है। तो इस बात को ध्यान में रखते हुए कि मैंने एक नए हाइब्रिड प्रबंधन समाधान कार्य को बनाने में तेजी से काम किया है, इस पीआर को देखें:
https://github.com/docker/docker/pull/9006

यह काम इस पर निर्भर करता है:
1) lvm2> = 2.02.112
2) डीएम पतले-पूल लक्ष्य संस्करण> = v1.14.0 (लिनक्स 3.19 समावेश के लिए लिनक्स-नेक्स्ट में उर्फ ​​परिवर्तन का मंचन किया गया)

RHEL7.1 में ये बदलाव होंगे। और RHELAH (परमाणु मेजबान) भी होगा। कोई अन्य डिस्ट्रोस / उत्पाद जो डीएम पतले-प्रावधान पर ठीक से डॉकटर तैनात करना चाहते हैं।

@snitm हाँ - मैं उन उपयोगकर्ताओं की संख्या को कम करने की कोशिश कर रहा हूं, जो एक अजीब टूट-फूट से प्रभावित हैं, जो तब किसी को यह महसूस करने में अधिक समय लगता है कि यह यह अस्पष्ट दर्द हो सकता है, फिर उपयोगकर्ता से यह जानने की कोशिश करें कुछ रहस्य पैच की कमी समस्या है।

और इसलिए आपकी शेष जानकारी के संदर्भ में - मैं गुठली की संख्या को कम करना चाहता हूं जो इस भयानक आश्चर्य का कारण बनेगी :)

@SvenDowideit ठीक है, मैंने यह जानकारी प्रदान की कि https://github.com/docker/docker/issues/3182ississececomment -63706507

@snitm , @AaronFriel
मैं AWS बीनस्टॉक, अमेज़न AMI पर इस मुद्दे की तरह लगता है में चल रहा हूँ।
(अंतरिक्ष से बाहर चल रहा है)
लिनक्स आईपी -172-31-63-145 3.14.23-22.44.amzn1.x86_64 # 1 एसएमपी मंगल नवम्बर 11 23:07:48 यूटीसी 2014 x86_64 x86_64 x86_64 GNU / लिनक्स

$ sudo docker संस्करण
क्लाइंट संस्करण: 1.3.2
क्लाइंट एपीआई संस्करण: 1.15
गो संस्करण (ग्राहक): go1.3.3
Git कमिट (ग्राहक): c78088f / 1.3.2
OS / Arch (क्लाइंट): linux / amd64
सर्वर संस्करण: 1.3.2
सर्वर एपीआई संस्करण: 1.15
गो संस्करण (सर्वर): go1.3.3
Git कमिट (सर्वर): c78088f / 1.3.2

मुझे अब भी यह त्रुटि Ubuntu 14.04 और Docker 1.4.1 के साथ मिल रही है।

पतले-पूल और पतले संस्करणों पर ध्यान न दें> = 1.12.0 का मतलब है कि आप ठीक हैं, हम 2.6.32-431.29.2.el6.x86_64 कर्नेल और dmsetup लक्ष्य रिपोर्ट के साथ CentOS 6.5 VMs चला रहे हैं। पतले-पूल और पतले दोनों v1.12.0 हैं। हालाँकि, मैं एक 40GB डेटा फ़ाइल के साथ फंस गया हूँ जो स्वयं को मुक्त नहीं कर रही है।

इस बग के साथ CentOS / RHEL 6.5 पर चलने वाले निहितार्थ क्या हैं? क्या आप रिक्त स्थान के साथ> = 100G के साथ ठीक हैं। मुझे लगता है कि यह अंततः किसी भी आकार की डिस्क को भरता है? या यह 100G पर बाध्य है?

ध्यान रखें कि 6.5 में कर्नेल के लिए उपलब्ध नवीनतम कर्नेल नहीं है। मैं 6.6 को एक साधारण 'यम अपडेट' और 2.6.32-504.3.3 कर्नेल के साथ परीक्षण करने के लिए रिबूट की सिफारिश करूंगा।

CentOS 6 के लिए बहुत नवीनतम कर्नेल और डिस्ट्रो अपडेट की पुष्टि करें ठीक है और अंतरिक्ष जारी करता है।

ripienaar: क्या आप स्पष्ट रूप से बता सकते हैं कि कौन सा CentOS 6 और कर्नेल संस्करण आप उपयोग कर रहे हैं? मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि जब मैं जानकारी को पास करूं, मेरे पास मेरी जरूरत की सभी जानकारी हो।

धन्यवाद।

जैसा कि @reiz ने ऊपर टिप्पणी की थी, यह Ubuntu 14.04 + नवीनतम

मूल 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

उपयोग:

# 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

उस कर्नेल पर जाने से पहले यह स्थान को पुनर्प्राप्त नहीं करेगा।

@jperrin इसका उल्लेख

मैं वर्तमान में Oracle एंटरप्राइज़ लिनक्स 3.8 UEK में से एक का उपयोग कर रहा हूं।

क्या इस स्थिति के लिए कोई समाधान है? AWS में केवल उदाहरण को फिर से बनाना आसान है, लेकिन स्थानीय विकास के माहौल में नोटिस करना अच्छा नहीं है / doer के कारण डिवाइस-मैपर द्वारा 90% में / var विभाजन का स्वामित्व है; जल्द ही लॉग या जर्नल के लिए भी जगह नहीं होगी

@donrudo ऊपर - नवीनतम सेंटोस 6 - 504.3.3 कर्नेल पर अपडेट करें।

यह सेंटो के लिए ठीक है, लेकिन हमारे कुछ देवता फेडोरा और अन्य ओपनस्यूज का उपयोग कर रहे हैं।

सभी डीएम पतले प्रोविजनिंग परिवर्तन पहले ऊपर की ओर भेजे जाते हैं। तो अगर Centos 6 तय हो गया है तो यह भी ऊपर की तरफ तय है। विभिन्न डिस्ट्रोस को फिक्स को वापस खींचने या अधिक आक्रामक तरीके से रिबास करने की आवश्यकता होती है।

@ripienaar मैं फिर से पूछूंगा, क्या आपको पता है कि किस कर्नेल कमिट (या कमिट का सेट) को फिक्स के लिए आवश्यक है?

@lexinator नोप

मैं इस मुद्दे को Ubuntu 14.04 ट्रस्टी और कर्नेल 3.13.0-36-जेनेरिक पर देख रहा हूं। संभावित समाधान निर्देशिका के लिए एडब्ल्यूएस ईबीएस भंडारण संलग्न कर रहा है ताकि यह अनिश्चित काल तक स्केल कर सके।

दोस्तों, यह मुद्दा वास्तव में दर्द देता है। CoreOS अभी ext4 पर जा रहा है और जल्द ही हमें CoreOS पर भी यह सारी परेशानियाँ होंगी।

लोग docker (dev या prod में) का उपयोग कैसे कर सकते हैं, जबकि यह मुद्दा एक वर्ष से अधिक समय तक अपरिचित है? हर कोई अंतहीन डिस्क है?

मेरा मानना ​​है कि वे ext4 के लिए आगे बढ़ रहे हैं devmapper नहीं। लेकिन है कि
सड़क पर सिर्फ शब्द ...

बुधवार, 28 जनवरी, 2015 को सर्गेई नोटिफिकेशन @

दोस्तों, यह मुद्दा वास्तव में दर्द देता है। CoreOS अब और जल्द ही ext4 पर जा रहा है
कोरोस पर भी यह सब परेशानी होगी।

लोग डॉक का उपयोग कैसे कर सकते हैं (देव या ठेस में) जबकि यह मुद्दा इसके लिए अपरिचित है
एक साल से भी अधिक? हर कोई अंतहीन डिस्क है?

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/3182#issuecomment -71800923

मैं उलझन में हूं। Google उदाहरण पर मेरा डिस्क स्थान केवल 10G है, लेकिन / var / lib / docker / devicemapper / devicemapper / डेटा का आकार 100G के रूप में दिखाया गया है। मैं सभी कंटेनरों और छवियों को हटाने के बाद भी अंतरिक्ष को पुनः प्राप्त करने में सक्षम नहीं हूं।

यह एक विरल फ़ाइल है। का प्रयोग करें ls -sh के बजाय ls -l , या एकांतर, du -h

मैं Ubuntu 13.04 पर यह रिपोर्ट कर सकता हूं (शायद आश्चर्य नहीं)।

क्या इस समय एकमात्र वास्तविक समाधान यह है कि डेविसमैपर की वृद्धि का अनुमान लगाने के लिए पर्याप्त डिस्क स्थान का प्रावधान किया जाए?

यह पूरा धागा काफी हास्यास्पद है। एक शिकायत के बाद एक डेबियन उपयोगकर्ता। यदि आप एक समस्या देख रहे हैं, तो आपको या तो एक डिस्ट्रो पर स्विच करना चाहिए जिसे ठीक से बनाए रखा जाए या अपने डिस्ट्रो मेंटेनरों के साथ काम करके उन्हें समस्या को ठीक करने के लिए प्राप्त करें। ये डिस्ट्रोक्स सुधार या सुधार के साथ नहीं हैं। मैं किसी के लिए भविष्य के सभी अनुरोधों को नजरअंदाज कर रहा हूँ, इस समस्या को दूर करने के लिए $ f को देखते हुए फिक्स को पहले से ही स्पष्ट रूप से ऊपर की ओर देखा जाता है (CentOS या RHEL देखें)। कृपया प्रश्न में टूटे हुए डिस्ट्रो के खिलाफ एक बग खोलें और इस मुद्दे को देखें।

यह उस समय हास्यास्पद नहीं है जब डॉकर ने कहा कि उनके पास निम्नलिखित प्लेटफार्मों पर समर्थन है:

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)

14.04 के लिए आपके पास कंबल समर्थन कॉल कैसे हो सकता है जब यह मुद्दा स्पष्ट रूप से प्रचलित है। डॉकर को स्पष्ट रूप से कुछ वितरणों पर कुछ गुठली के लिए कंबल का समर्थन छोड़ देना चाहिए।

मैं CentOS और कर्नेल अपग्रेड का उपयोग कर रहा हूं, इससे रनवैक्यूमर उपयोग समस्या में सुधार हुआ है।

भले ही, आपके काम के लिए धन्यवाद @snitm

उबंटू पर इस मुद्दे को रखने वालों के लिए, सुनिश्चित करें कि आप पुराने डॉकटर चित्रों / कंटेनरों की उचित सफाई कर रहे हैं। मैंने पाया कि जब मैंने सोचा था कि मेरी सफाई स्क्रिप्ट नहीं चल रही थी, और इसीलिए यह इतनी जगह का उपयोग कर रहा था।

`` `#! / बिन / बैश

सभी कंटेनरों को हटा दें

docker rm $ (docker ps -a -q)

सभी छवियों को हटा दें

docker rmi $ (docker छवियाँ -q)
`` `

@ टायलरमिल्स ने ध्यान दिया कि कंटेनर द्वारा बनाए गए docker rm _not_ को हटा देंगे। यदि आपके कंटेनर वॉल्यूम का उपयोग करते हैं, तो आपको डॉक करने के साथ-साथ वॉल्यूम हटाने के लिए docker rm -v का उपयोग करना चाहिए।

@snitm हमें इसके साथ ही बिट भी मिला (उबंटू 14.04 का उपयोग करके)। हालांकि यह विशेष रूप से डॉकटर की गलती नहीं हो सकती है, उन्हें इसे ठीक करने में एक मजबूत रुचि होनी चाहिए क्योंकि यह पूरे अनुभव पर खराब रूप से प्रतिबिंबित करता है।

यह भी ध्यान दें कि मैं इस समस्या से टकरा गया हूँ और यही मैंने इसे ठीक करने के लिए किया है:

मेरे मामले में हालांकि, डिवाइस के कारण / var 100% उपयोग तक पहुंचने पर आरोहित होता है, मेजबान को कर्नेल घबराहट में जाने से रोकने का एकमात्र तरीका है कि सीधे docker प्रक्रिया को मार दिया जाए (अर्थात किसी भी docker कमांड को जारी करने से घबराहट होगी)।

फिर मैन्युअल रूप से इस आदेश का उपयोग करके डेविसेमर मैप्स का उपयोग करके किसी भी प्रक्रिया को मारें:

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

तब मैं किसी भी devicemapper आरोह का उपयोग करने में सक्षम था:

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

उन चरणों ने सभी फ़ाइल डिस्क्रिप्टर को जारी किया, जिसने मुझे अंतरिक्ष को पुनः प्राप्त करने / जो भी फाइलें हटाने की अनुमति दी ..

मेरे मामले में उस बिंदु पर, इसे / अधिक / अधिक स्थान के साथ माउंट करने के लिए / var / lib / docker निर्देशिका को स्थानांतरित करने के लिए अधिक समझ में आया और -g तर्क का उपयोग करके एक अलग होम निर्देशिका का उपयोग करने के लिए docker डेमन को कॉन्फ़िगर करें

एडम मिलर के माध्यम से

@Dekz टिप्पणी के बाद, यह शायद एक अच्छा विचार होगा यदि इंस्टॉलेशन गाइड ने उपयोगकर्ताओं को यह निर्देश नहीं दिया कि इस फिक्स के बिना कर्नेल संस्करण स्वीकार्य हैं जैसा कि यहां किया गया है: https://docs.docker.com/installation/ubuntulinux/

साभार @JohnMorales डॉकर से इस बारे में थोड़ी चेतावनी एक महान विचार होगा।

+1

+1

हमने हाल ही में इस रनिंग उबंटू 14.04.2 LTS (3.16.0-30-जेनेरिक) से थोड़ा सा मिला और अभी भी एक समाधान खोजने के लिए छटपटा रहे हैं। ऐसा लगता है कि या तो CentOS 6.6 पर स्विच करना (जिसमें माना जाता है कि कर्नेल फिक्स है) या वॉल्यूम को बढ़ाना जिसमें एक बड़ी डिस्क है एकमात्र समाधान है।

क्या उबंटू चलाने वाले को स्वीकार्य वर्कअराउंड मिल गया है?

मैं सहमत हूं - डॉकटर को इस मुद्दे को उठाना चाहिए और संबोधित करना चाहिए - यह एक गंभीर बग है जिसे दस्तावेज़ीकरण और चेतावनी संदेशों की आवश्यकता है, इसलिए अधिक लोग भोलेपन से एक ही जाल में नहीं पड़ते।

मैं @natea से सहमत हूं
मैं redhat 6.5 के साथ एक ही मुद्दे का सामना कर रहा हूं और यह एक बड़ा सवालिया निशान लगा रहा है कि क्या docker तैयार है और हम विकल्प तलाशने लगे हैं।
मुझे इस मुद्दे को हल करने के लिए मैन्युअल वर्कअराउंड करने में भी कोई आपत्ति नहीं है, लेकिन अभी, मैं किसी भी संभव व्यक्ति के बारे में नहीं जानता।

@sagiegurarie जानते हैं कि हमने 6.5 (और संबद्ध कर्नेल) के साथ विभिन्न मुद्दों के कारण CentOS के लिए आवश्यकताओं को 6.6 कर दिया। यह आवश्यकता शायद अभी तक लाइव डॉक्स-वेबसाइट पर नहीं है, लेकिन अगली रिलीज के साथ होगी, शायद उससे पहले।

इसलिए मुद्दा # 11643 उत्तर प्रासंगिक नहीं है? इसका मतलब है कि हम redhat 6.5 का उपयोग नहीं कर सकते हैं?

@natea @sagiegurari हमारे लिए क्या काम करता है यह मैनुअल "फिक्स" @TylerMills द्वारा

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

निश्चित रूप से नकारात्मक पक्ष यह है कि आपको फिर से सभी छवियों को फिर से खींचना होगा और कंटेनरों को फिर से चलाना होगा।

@bkeroackdsc मुझे याद है कि मैंने पहले भी सभी कंटेनरों और छवियों को हटा दिया था और इसका हल नहीं

नमस्कार! मैं जानना चाहूंगा कि क्या यह मुद्दा अभी भी ubuntu-15.04 पर मौजूद है। जो अब linux-3.19 कर्नेल पर है। बहुत धन्यवाद।

यदि आप उस कर्नेल के साथ ubuntu-15.05 पर हैं तो ओवरले का उपयोग क्यों नहीं करें, यह तरीका है
devicemapper से बेहतर है

Thu पर, 7 मई, 2015 को पूर्वाह्न 11:26 पर, Dreamcat4 सूचनाएं @github.com ने लिखा:

नमस्कार! मैं जानना चाहूंगा कि क्या यह मुद्दा अभी भी ubuntu-15.04 पर मौजूद है।
जो अब linux-3.19 कर्नेल पर है। बहुत धन्यवाद।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/3182#issuecomment -99968299।

@jfrazelle ओह ठीक है। यह कैसा है? क्या आप ओवरले का उपयोग करते हैं? मैं इस धारणा (अब तक) के तहत जा रहा हूं कि ओवरले समर्थन अभी भी 3.19 कर्नेल के रूप में प्रयोगात्मक था।

हां मैं ओवरले का उपयोग करता हूं :) हम 1.7 में से सूची खो जाने की उम्मीद कर रहे हैं
इसे इस्तेमाल करें और इसे प्यार करें

गुरुवार, 7 मई, 2015 को, Dreamcat4 नोटिफिकेशन @github.com ने लिखा:

@jfrazelle https://github.com/jfrazelle ओह ठीक है। यह कैसा है? कर
आप ओवरले का उपयोग करते हैं? मैं इस धारणा के तहत जा रहा हूं (अब तक)
ओवरले समर्थन अभी भी 3.19 कर्नेल के रूप में प्रयोगात्मक था।

-
इस ईमेल का उत्तर सीधे दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/3182#issuecomment -99982543

@sagiegurari आप 6.5 से क्यों

@jperrin क्योंकि यह मेरा निर्णय नहीं है :)
वैसे भी मैं सभी टीमों के साथ यह देखने की कोशिश कर रहा हूं कि क्या उत्पादन 7 के लिए ठीक रहेगा।

यह अभी भी CentOS7 (3.10.0-123.el7.x86_64) पर एक मुद्दा लगता है। मैंने एक नया CentOS बॉक्स सेटअप किया है और डॉकटर v1.6.0 स्थापित किया है। सुडोकू डेटा फ़ाइल एक sudo docker rmi के बाद आकार कभी नहीं घटती है। मैं उस पर कोशिश करने के लिए एक CentOS6.6 बॉक्स प्राप्त कर रहा हूं।

Ubuntu 14.04 पर v1.6.0 का सकारात्मक प्रभाव (v1.5.0 से अधिक) पर लग रहा था

यह भी लगता है कि सेंटो 7 पर अच्छा काम करता है जो मुझे लगता है कि रेडहैट 7 के लिए भी कह सकता है
लेकिन 6.5 redhat नहीं है, और मैं डॉक्स में यह बताने का सुझाव देता हूं।

यह नवीनतम अपस्ट्रीम डॉकटर में काम करना चाहिए। और @sagiegurari की अंतिम टिप्पणी का अर्थ है कि (सेंटोस 7 पर काम करता है)।

अगर ऐसा है, तो हमें इस बग को बंद कर देना चाहिए।

तो क्या यह समस्या अभी भी नवीनतम डॉकटर के साथ हो रही है? यदि नहीं, तो इसे बंद करने दें।

अच्छा .... अधिक परीक्षण चलाने से अनिश्चित परिणाम मिलते हैं।
अपनी बेहतर कहने की अनुमति देता है, लेकिन अभी भी लीक हो सकता है, बस बहुत धीमी हो सकती है।
मैं पुष्टि करने के लिए और अधिक जांच चलाऊंगा।

@sagiegurari

क्या आप मुझे इस मुद्दे पर कुछ और जानकारी दे सकते हैं कि आप क्या समस्या का सामना कर रहे हैं और आपके पर्यावरण का भी। इस मुद्दे का शीर्षक कहता है कि छवि / कंटेनर विलोपन के लिए स्थान को पुन: प्राप्त नहीं किया गया है, और नवीनतम अपस्ट्रीम डॉकटर के पास ऐसा कोई मुद्दा नहीं होना चाहिए।

क्या आप कृपया अपस्ट्रीम डॉकटर ले सकते हैं, डायनेमिक बाइनरी का निर्माण कर सकते हैं, एक नया पतला पूल बना सकते हैं (फ्रेश / var / lib / docker /) डायरेक्टरी में, एक इमेज खीचें, उसे डिलीट करें और docker info को देखें और देखें कि क्या स्पेस फ्री हो गया है या नहीं।

मैं अधिक सटीक जानकारी प्रदान करने के लिए अगले सप्ताह उम्मीद से अधिक परीक्षण चलाऊंगा।

मैं मानता हूँ कि हम इसे अपनी निर्माण मशीन में देखते हैं जहाँ हम बहुत सारी छवियाँ बनाते हैं और हटाते हैं (निर्माण के दौरान) + docker रजिस्ट्री 2.0 चलाते हैं (जिस पर हम हमेशा टैग 'नवीनतम' के साथ अलग-अलग छवियों को धक्का देते हैं) + कुछ कंटेनरों को चलाते हैं प्रारंभिक परीक्षण करते हैं कि सब कुछ ठीक काम करता है (परीक्षण वास्तव में उस मशीन पर चलने वाला नहीं है, लेकिन हम प्रारंभिक चरण में हैं इसलिए हम बहुत सारे कंटेनर बनाते / रोकते हैं / आरएम करते हैं)।

हमारी छवियां वास्तव में बड़ी हैं, कभी-कभी मुझे 2 जीबी से अधिक का आभासी आकार दिखाई देता है, इसलिए यदि कोई समस्या है, तो यह खुद को सामान्य छवियों के साथ तेजी से दिखाता है जो सामान्य रूप से 400mg के आसपास हैं।

किसी भी तरह, मैं व्यवहार को देखने के लिए कुछ परीक्षण चलाने की कोशिश करूंगा और अगले सप्ताह अधिक जानकारी प्रदान करूंगा।

डॉकर संस्करण 1.6.0 का उपयोग करके, लिनक्स कर्नेल पर 3.49.35-28.38.amzn1.x86_64 पर 4749651 / 1.6.0 का निर्माण करें

छवियों को हटाने से डिस्क स्पेस का दावा कम हो जाता है।

@vbatts

क्या हम इस मुद्दे को बंद कर सकते हैं मुझे नहीं लगता कि नवीनतम डॉक में हमें ऊप फाइलों से छवि / कंटेनर स्थान को पुनः प्राप्त करने की समस्या है। यदि कुछ विशिष्ट आता है, तो कोई विशिष्ट विवरण के साथ एक नया मुद्दा खोल सकता है।

@rhvgoyal मुझे इतने सारे प्लेटफार्मों / संस्करणों के बारे में इतने सारे लोगों की शिकायत के बाद इस मुद्दे को

@sagiegurari

मुझे नहीं पता कि हम मुद्दे को खुला रखकर क्या हासिल करते हैं। मुझे पता है कि यह अपस्ट्रीम है। बहुत सारे मुद्दे हैं जो खुले हैं। लोग उन्हें टिप्पणियों को नोट करने के लिए डैशबोर्ड के रूप में उपयोग कर रहे हैं।

मुझे लगता है कि किसी मुद्दे को खुला रखने से ही समझ में आता है कि क्या वास्तविक प्रजनन योग्य समस्या है। अन्यथा मुद्दों की यह सूची बस बढ़ती रहती है और यह पता लगाना मुश्किल है कि किस पर ध्यान केंद्रित किया जाए।

आपके पास एक बार इस मुद्दे पर अधिक डेटा जोड़ने से कोई नहीं रोकता है।

@rvgoyal आप किस टैग को नवीनतम अपस्ट्रीम द्वारा संदर्भित कर रहे हैं?

@rhvgoyal कहो नवीनतम प्रतिबद्ध। मैं सिर्फ नवीनतम गिट ट्री को क्लोन करता हूं और परीक्षण करता हूं। क्या यह वास्तव में मायने रखता है?

पुराने डॉकटर रिलीज और पुरानी गुठली पर बहुत सारी समस्याएं बताई गई हैं। मुझे लगता है कि पहला कदम यह देखना चाहिए कि क्या नवीनतम डॉकटर और अपेक्षाकृत नए कर्नेल पर समान समस्या दिखाई दे रही है। अगर यह अभी भी एक समस्या है या कुछ ऐसा है जो पुराने संस्करणों में तय नहीं है तो हमें एक विचार देता है।

जब कोई वापस आता है और भविष्य में इसे पढ़ता है, तो हाँ। मैं जानना चाहता था कि यह किस संस्करण में तय किया गया था।

हम लूपबैक उपकरणों के मामले में डिस्क जारी करते हैं। यह वास्तव में बहुत पहले किया गया था। मुझे लगता है कि 1.6 यह होना चाहिए।

@stanislavb ने 1.6 के साथ परीक्षण किया और इसने उसके लिए काम किया।

यदि आप इस मुद्दे में मेरी पहली टिप्पणी का उल्लेख करते हैं, तो आप देखेंगे कि मैंने सेंटोस 7 पर v1.6.0 के साथ भी कोशिश की थी और अभी भी मुद्दा था।

@alexDrinkwater

ठीक है, क्या आप इसे पुन: पेश करने में सक्षम हैं? आपने किस तरह के पतले पूल का उपयोग किया (लूप डिवाइस के शीर्ष पर?)। क्या आपने डॉकटर को पुनः आरंभ किया है या यह पहली बार होता है जब आप डॉक करने लगते हैं?

कुछ मामलों में ऐसा हो सकता है कि डॉक लूप उपकरणों का उपयोग कर रहा है और फिर डॉक को फिर से चालू किया जाता है, ऐसा हो सकता है कि पूल बंद नहीं था क्योंकि कुछ डिवाइस कहीं व्यस्त था। पुनः आरंभ करने वाले पर
पूल को पहले से ही ढूँढता है और उसे इस बात का कोई ज्ञान नहीं है कि लूपबैक उपकरणों का उपयोग किया जा रहा है और यह जारी नहीं करता है। मैं सोच रहा हूँ कि क्या आप उस सिट्टाईटोन में भाग गए?

सेंटोस 7

डॉकर संस्करण 1.6.2.el7, c3ca5bb / 1.6.2 का निर्माण करें

छवि सफाई से पहले

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

कुछ डॉकटर रमी के बाद

[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

ठीक है, अभी मैंने एक सेंटोस 7 छवि को बूट किया है और डॉकटर 1.6 की कोशिश की है और मुझे समस्या नहीं दिख रही है। यहाँ कदम हैं।

[ रूट @ सेंटोस 7-जेनेरिक ~] #
क्लाइंट संस्करण: 1.6.0
क्लाइंट एपीआई संस्करण: 1.18
गो संस्करण (ग्राहक): go1.4.2
Git प्रतिबद्ध (ग्राहक): 8aae715 / 1.6.0
OS / Arch (क्लाइंट): linux / amd64
सर्वर संस्करण: 1.6.0
सर्वर एपीआई संस्करण: 1.18
गो संस्करण (सर्वर): go1.4.2
Git कमिट (सर्वर): 8aae715 / 1.6.0
OS / Arch (सर्वर): linux / amd64

पहले से ही एक छवि आयात की गई है।

[ रूट @ सेंटोस 7-जेनेरिक ~] #
रिपोजिटरी टाग इमेज आईडी सृजित वायरल आकार
docker.io/fedora नवीनतम ded7cd95e059 2 सप्ताह पहले 186.5 MB

यहाँ docker info का आउटपुट है।

रूट @ सेंटोस 7-जेनेरिक ~] #
कंटेनर: 0
चित्र: 2
स्टोरेज ड्राइवर: devicemapper
पूल का नाम: docker-253: 1-50331788-पूल
पूल अवरोधक: 65.54 kB
बैकिंग फाइलसिस्टम: xfs
डेटा फ़ाइल: / dev / loop0
मेटाडेटा फ़ाइल: / dev / loop1
डेटा स्पेस प्रयुक्त: 525.5 एमबी
डेटा स्पेस कुल: 107.4 जीबी
डेटा स्पेस उपलब्ध: 20 जीबी
मेटाडाटा स्पेस प्रयुक्त: 892.9 kB
मेटाडाटा स्पेस कुल: 2.147 जीबी
मेटाडाटा स्पेस उपलब्ध: 2.147 जीबी
उदय सिंक समर्थित: सच
डेटा लूप फ़ाइल: / var / lib / docker / devicemapper / devicemapper / data
मेटाडेटा लूप फ़ाइल: / var / lib / docker / devicemapper / devicemapper / मेटाडेटा
लाइब्रेरी संस्करण: 1.02.93-RHEL7 (2015-01-28)
निष्पादन चालक: देशी-0.2
कर्नेल संस्करण: 3.10.0-229.el7.x86_64
ऑपरेटिंग सिस्टम: CentOS Linux 7 (कोर)
सीपीयू: 2

[ रूट @ सेंटोस 7-जेनेरिक ~] #
अप्रकाशित: फेडोरा: नवीनतम
हटा दिया गया: ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4
हटाए गए: 48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731

[ रूट @ सेंटोस 7-जेनेरिक ~] #
कंटेनर: 0
छवियाँ: 0
स्टोरेज ड्राइवर: devicemapper
पूल का नाम: docker-253: 1-50331788-पूल
पूल अवरोधक: 65.54 kB
बैकिंग फाइलसिस्टम: xfs
डेटा फ़ाइल: / dev / loop0
मेटाडेटा फ़ाइल: / dev / loop1
डेटा स्पेस प्रयुक्त: 307.2 एमबी
डेटा स्पेस कुल: 107.4 जीबी
डेटा स्पेस उपलब्ध: 20.22 जीबी
मेटाडाटा स्पेस प्रयुक्त: 733.2 kB
मेटाडाटा स्पेस कुल: 2.147 जीबी
मेटाडाटा स्पेस उपलब्ध: 2.147 जीबी
उदय सिंक समर्थित: सच
डेटा लूप फ़ाइल: / var / lib / docker / devicemapper / devicemapper / data
मेटाडेटा लूप फ़ाइल: / var / lib / docker / devicemapper / devicemapper / मेटाडेटा
लाइब्रेरी संस्करण: 1.02.93-RHEL7 (2015-01-28)
निष्पादन चालक: देशी-0.2
कर्नेल संस्करण: 3.10.0-229.el7.x86_64
ऑपरेटिंग सिस्टम: CentOS Linux 7 (कोर)
सीपीयू: 2

सूचना डेटा उपयोग 525MB से घटकर 307MB हो गया। तो एक छवि को हटाने से मुझे जगह वापस मिल गई।

ठीक है, मैं ऑपरेशन से पहले और बाद में लूप फ़ाइल का आकार पेस्ट करना भूल गया। यही पर है।

• छवि खींचने से पहले।
  $ cd / var / lib / docker / devicemapper / devicemapper
  $ डु-एच डेटा
  293M डेटा
• छवि खींचने के बाद
  [ root @ centos7-generic devicemapper] # du -h डेटा
  499M डेटा
• छवि हटाने के बाद
  [ root @ centos7-generic devicemapper] # du -h डेटा
  293M डेटा

तो मेरा लूप फ़ाइल वास्तव में छवि हटाने के बाद सिकुड़ जाता है। मुझे लगता है कि आप किस बारे में शिकायत कर रहे हैं।

@stanislavb

क्या आप लूप फ़ाइलों का उपयोग कर रहे हैं? वे आपकी डॉक जानकारी में दिखाई नहीं दे रहे हैं। मुझे लगता है कि आप उसी मुद्दे पर चल रहे हैं जब पूल शुरू हुआ था।

क्या आप लूप बैकिंग फाइलों (/ var / lib / docker / devicemapper / devicemapper / data) के आकार की जांच कर सकते हैं और सुनिश्चित कर सकते हैं कि फाइल डिलीट होने के बाद सिकुड़ जाए। (डु -ह)।

@rhvgoyal
सेंटोस 7, डॉकर संस्करण 1.6.2.el7, 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

ठीक है, तो लूप डिवाइस का आकार वास्तव में नीचे जा रहा है।

इसके अलावा मैंने कोड से सत्यापित किया है। हम फिर से जारी करेंगे भले ही पुनः आरंभ करने वाले को पतला पूल मिला हो।

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

उपरोक्त कोड के अनुसार, यदि उपयोगकर्ता या तो डेटा ब्लॉक डिवाइस या एक पतले पूल में पारित हो जाता है, तो ही डिसॉर्डर अक्षम होता है। यह देखते हुए कि हम या तो पास नहीं हुए थे, अभी भी डिस्चार्ज जारी है। इसलिए यह आपके लिए काम कर रहा है।

@alexDrinkwater अब हमारे पास दो डेटा पॉइंट हैं जो कि 1.6 में तय किए गए हैं। क्या आपको अभी भी इस मुद्दे को बंद करने में चिंता है।

सेंटोस 6.6

डॉकर संस्करण 1.5.0, a8a31ef / 1.5.0 का निर्माण करें

छवि सफाई से पहले

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

शेष 1929 छवियों पर डेटा फ़ाइल का आकार चेक किया गया

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

कुछ डॉकटर रमी के बाद

[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

ठीक है, तो 1.5 में भी यह काम करता है।

मैंने एक नई मशीन पर इसका परीक्षण किया।

डॉकर संस्करण 1.6.0, 8aae715 / 1.6.0 का निर्माण करें

खींचने से पहले:

/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

खींचने के बाद:

/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

छवि निकालें:

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

हटाने के बाद:

/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

अगर आपको मेरी मशीन या संस्करण आदि के बारे में अधिक जानकारी है तो मुझे बताएं

@alexDrinkwater

ऐसा लगता है कि आप / var पर एक अलग डिवाइस माउंट कर रहे हैं। उस डिवाइस पर फ़ाइल सिस्टम क्या है और माउंट विकल्प क्या हैं?

इसके अलावा आप मुझे निम्नलिखित दे सकते हैं।

• dmsetup तालिका
• dmsetup की स्थिति
• बिल्ली / आदि / sysconfig / docker- भंडारण

क्या आप xfs फाइल सिस्टम के साथ रूट पर / var रखने के सरल मामले को आज़मा सकते हैं। समस्या को थोड़ा कम करने की कोशिश की जा रही है।

@alexDrinkwater

मैंने ext4 विभाजन के साथ / var / lib / docker पर एक और डिस्क लगाई ताकि लूपबैक बैकिंग फाइलें ext4 (xfs के बजाय) पर हों और फिर भी चीजें मेरे लिए काम कर रही हों।

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

वास्तव में निश्चित नहीं है कि आपके सेटअप के बारे में क्या खास है।

विस्तार से,

• खींचने से पहले
  / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / docker
• छवि खींचने के बाद
  / dev / vdb1 9.8G 544M 8.7G 6% / var / lib / docker
• छवि हटाने के बाद
  / dev / vdb1 9.8G 338M 8.9G 4% / var / lib / docker

@alexDrinkwater

आपके सेटअप और मेरे सेटअप के बीच अन्य प्रमुख अंतर कर्नेल संस्करण है। आप "3.10.0-229.el7.x86_64" का उपयोग कर रहे हैं, जबकि आप "3.10.0-123.el7.x86_64" का उपयोग कर रहे हैं। क्या आप अपने कर्नेल को अपग्रेड कर सकते हैं और इसे आज़मा सकते हैं।

मदद के लिए धन्यवाद @ श्रवण मैं आज कर्नेल को अपडेट नहीं कर पाऊंगा। लेकिन यहां आपके द्वारा मांगी गई सेटिंग्स हैं:

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

मेरे पास कोई कस्टम भंडारण विकल्प कॉन्फ़िगर नहीं है।

मिल गया। मुझे लगता है कि यह ext3 फ़ाइल सिस्टम के साथ कुछ करना है। मैं समस्या भी देख सकता हूं। किसी भिन्न फ़ाइल सिस्टम का प्रयास करें, ext4 या xfs कहें और आपको समस्या का सामना नहीं करना पड़ेगा।

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

• चित्र खींचने से पहले
  [ root @ centos7-generic-2 devicemapper] # du -h डेटा
  293M डेटा
• चित्र खींचने के बाद
  [ root @ centos7-generic-2 devicemapper] # du -h डेटा
  501M डेटा
• छवि हटाने के बाद
  [ root @ centos7-generic-2 devicemapper] # du -h डेटा
  501M डेटा

तो किसी कारण से अगर लूपबैक फ़ाइल ext3 फाइल सिस्टम पर है, तो यह काम नहीं करता है। हो सकता है ext3 काफी पुराना हो, लूप डिस्क उस पर काम नहीं करता है।

धन्यवाद, जैसे ही मैंने देखा कि फाइलसिस्टम एक्स 3 था मैंने सोचा कि यह हो सकता है। मुझे लगता है कि यदि आप ext3 पर समस्या को पुन: पेश करने में सक्षम थे तो हम इस मुद्दे को बंद कर सकते हैं। यह दूसरों के लिए एक अच्छा संदर्भ होगा।

संदर्भ के लिए, मेरे काम करने के उदाहरण एक्सएफ़एस फाइलसिस्टम पर डॉकर 1.6.2 और एक्सल 4 पर डॉकर 1.6.0 और 1.5.0 थे।

@vbatts

क्या हम इसे बंद कर सकते हैं। स्पेस रिकॉल एक्सएफ और एक्सटी 4 पर ठीक काम करता है। ext3 इसका समर्थन करने के लिए बहुत पुराना प्रतीत होता है।

@rhvgoyal @vbatts IIRC, एक संगतता-जांच है जो अंतर्निहित फ़ाइल-सिस्टम की जांच करती है। शायद हमें ext3 लिए एक चेक जोड़ना चाहिए अगर यह मुद्दा है?

संपादित करें:
सन्दर्भ के लिए; डेमॉन / graphdriver / ओवरले / overlay.go # L115

लूप ड्रायवर फ़ाइल में एक छेद को पंच करने के लिए फैलोकेट () का उपयोग करता है जब त्यागना आता है। लिनक्स मैन पेज ऑफ़ फालोकेट () सत्यापित करता है कि यह ext3 पर समर्थित नहीं है।

/ *
सभी फ़ाइल सिस्टम FALLOC_FL_PUNCH_HOLE का समर्थन नहीं करते हैं; यदि कोई फ़ाइल सिस्टम ऑपरेशन का समर्थन नहीं करता है, तो एक त्रुटि वापस आ जाती है। ऑपरेशन कम से कम निम्नलिखित फाइल सिस्टम पर समर्थित है:
* XFS (चूंकि लिनक्स 2.6.38)
* ext4 (लिनक्स 3.0 के बाद से)
* Btrfs (लिनक्स 3.7 के बाद से)
* tmpfs (लिनक्स 3.5 से)
* /

@thaJeztah

अगर कोई ext3 पर docker चलाना चाहता है, तो मुझे लगता है कि हमें इसकी अनुमति देनी चाहिए। बस यह कि उन्हें समर्थन नहीं मिलेगा इसलिए लूप फ़ाइल का आकार छोटा नहीं होगा जब छवि / कंटेनरों को हटा दिया जाएगा।

@ श्रवण docker info में यह दिखाने के बारे में कैसे? Udev Sync Supported आउटपुट के समान।

@thaJeztah

हम पहले से ही डॉक जानकारी "बैकिंग फाइल सिस्टम" में एक प्रविष्टि है। मुझे यकीन नहीं है कि यह ext2 / ext3 / ext4 के बारे में सटीक होने के बजाय extfs क्यों कहता है।

लॉग में स्टार्टअप समय पर एक चेतावनी हो सकती है। पतली पूल के लिए लूप उपकरणों का उपयोग करने के बारे में चेतावनी के समान।

@thaJeztah

और मुझे लगता है कि हमें यह तभी करना चाहिए जब बहुत से लोग इससे प्रभावित हों। यदि नहीं, तो हम केवल अधिक काम और कोड बना रहे हैं और यह इसके लायक नहीं हो सकता है।

syscall.Statfs_t संरचना, Type ext2, ext3, और ext4 पर सभी 0xef53 , और यही हम फाइलसिस्टम जादू का पता लगाने के लिए उपयोग कर रहे हैं।

syscall.Statfs_t संरचना, ext2, ext3, और ext4 पर टाइप फ़ील्ड के साथ 0xef53 पर वापस आती है, और यही हम फाइलसिस्टम मैजिक का पता लगाने के लिए उपयोग कर रहे हैं।

ओह। यह अच्छा होगा कि सूचना के मुद्दों को पहचानना आसान बनाने के लिए वह जानकारी हो।

मुझे लगता है, हमें बस इसे बंद कर देना चाहिए?

समापन के रूप में यह ext3 पुराना होने के साथ एक समस्या है। कृपया ext4 या xfs का उपयोग करें

क्या आपको लगता है कि यह मुख्य डॉक्यूमेंट डॉक्यूमेंटेशन में किसी तरह से बेहतर दस्तावेज हो सकता है?

मुद्दा फाइल सिस्टम के साथ है या नहीं, इस बात पर गौर करें कि हाल के दो मुद्दों में यह कितना भ्रम पैदा करता है।

धन्यवाद।

# 9786 जारी करने के लिए reterring

@dbits हाँ, मुझे लगता है कि ext3 के कुछ मुद्दों का उल्लेख डॉक्स में उल्लेख के लायक हो सकता है। अभी तक कोई पता नहीं है कि एक उपयुक्त स्थान क्या होगा।

XFS के साथ समान / समान समस्या है।
कर्नेल पर "3.10.0-123.el7.x86_64" था, लेकिन अब "3.10.0-229.el7.x86_64" पर अपडेट किया गया।

Eveything हटा दिया गया है (कंटेनर, चित्र) लेकिन डेटा में अभी भी 100GB है।
किसी भी विचार, मदद?

[ रूट @ docker0101 ~] # ls -alh / data / docker / devicemapper / devicemapper /
कुल 80 जी
drwx ------ 2 मूल जड़ 32 जून 8 16:48।
drwx ------ 5 मूल जड़ 50 जून 9 07:16 ।।
-rw ------- 1 रूट रूट 100G Jul 16 21:33 डेटा
-rw ------- 1 रूट रूट 2.0 जी जूल 17 09:20 मेटाडेटा

[ रूट @ docker0101 ~] #
लिनक्स docker0101 3.10.0-229.7.2.el7.x86_64 # 1 एसएमपी मंगल जून 23 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

[ रूट @ docker0101 ~] # बिल्ली / आदि /
CentOS Linux रिलीज़ 7.1.1503 (कोर)

[ रूट @ docker0101 ~] #
कंटेनर आईडी इमेजेज बनाई गई स्टेटस पोर्टल नाम

[ रूट @ docker0101 ~] #
रिपोजिटरी टाग इमेज आईडी सृजित वायरल आकार

[ रूट @ docker0101 ~] #
कंटेनर: 0
छवियाँ: 0
स्टोरेज ड्राइवर: devicemapper
पूल का नाम: docker-253: 0-268599424- पूल
पूल अवरोधक: 65.54 kB
बैकिंग फाइलसिस्टम: xfs
डेटा फ़ाइल: / dev / loop0
मेटाडेटा फ़ाइल: / dev / loop1
डेटा स्पेस प्रयुक्त: 85.61 जीबी
डेटा स्पेस कुल: 107.4 जीबी
डेटा स्पेस उपलब्ध: 40.91 एमबी
मेटाडाटा स्पेस प्रयुक्त: 211.4 एमबी
मेटाडाटा स्पेस कुल: 2.147 जीबी
मेटाडाटा स्पेस उपलब्ध: 40.91 एमबी
उदय सिंक समर्थित: सच
डेटा लूप फ़ाइल: / डेटा / docker / devicemapper / devicemapper / डेटा
मेटाडेटा लूप फ़ाइल: / डेटा / docker / devicemapper / devicemapper / मेटाडेटा
लाइब्रेरी संस्करण: 1.02.93-RHEL7 (2015-01-28)
निष्पादन चालक: देशी-0.2
कर्नेल संस्करण: 3.10.0-229.7.2.el7.x86_64
ऑपरेटिंग सिस्टम: CentOS Linux 7 (कोर)
सीपीयू: 4
कुल मेमोरी: 11.58 GiB
नाम: docker0101

[ रूट @ docker0101 ~] # dmsetup तालिका
vg1-lvol0: 0 167772160 रैखिक 8:16 2048
docker-253: 0-268599424-पूल: 0 209715200 पतला-पूल 7: 1 7: 0 128 32768 1 स्किप_ब्लॉक_ज़रोजिंग

[ रूट @ docker0101 ~] # dmsetup स्थिति
vg1-lvol0: 0 167772160 रैखिक
docker-253: 0-268599424-पूल: 0 209715200 पतला-पूल 71359 51606/524288 1306264/1638400

[ रूट @ docker0101 ~] # बिल्ली / आदि / sysconfig /
DOCKER_STORAGE_OPTIONS =

[ रूट @ docker0101 ~] # rpm -qi docker
नाम: docker
संस्करण: 1.6.2
रिलीज़: 14.el7.centos
आर्किटेक्चर: x86_64
स्थापना तिथि: शुक्र १EST जुलाई २०१५ 09:19:54 AM CEST
समूह: अनिर्दिष्ट
आकार: 33825026
लाइसेंस: एएसएल 2.0
हस्ताक्षर: RSA / SHA256, बुध 24 जून 2015 05:43:12 AM CEST, कुंजी आईडी 24c6a8a7f4a80eb5
स्रोत RPM: docker-1.6.2-14.el7.centos.src.rpm
बिल्ड तिथि: बुध 24 जून 2015 03:52:32 पूर्वाह्न सेस्ट
बिल्ड होस्ट: कार्यकर्ता 1.bsys.centos.org

[रूट @ docker0101 ~] # ls
lrwxrwxrwx 1 रूट रूट 12 Jun 9 08:21 / var / lib / docker -> / डेटा / रेंड

[ रूट @ docker0101 ~] # माउंट
/ dev / sda5 on / var प्रकार xfs (rw, relatime, attr2, inode64, noquota)
/ dev / mapper / vg1-lvol0 on / data type xfs (rw, relatime, attr2, inode64, noquota)

@tomlux आपके द्वारा उपयोग किए जा रहे docker के साथ आसानी से खिलौना बनाना है। गंभीर काम के लिए, लूपबैक धीमा हो जाएगा, और इसकी कुछ सीमाएं होंगी। मैं http://www.projectatomic.io/docs/docker-storage-recommendation/ पर पढ़ने की अत्यधिक सलाह देता हूं

आप बेहतर प्रदर्शन प्राप्त करेंगे, और इस तरह से चीजों को नहीं मारेंगे, यह मानते हुए कि आपने सभी सिस्टम अपडेट लागू कर दिए हैं।

@tomlux

क्या आप "-s" को ls में जोड़ सकते हैं। यह आपको डेटा और मेटाडेटा फ़ाइलों को आवंटित वास्तविक ब्लॉक देगा। अभी यह फाइलों का स्पष्ट आकार दिखा रहा है।

docker जानकारी आउटपुट हालांकि पेचीदा है। यह उच्च उपयोग दिखाने के लिए लगता है।

@tomlux

डेटा और मेटाडेटा फ़ाइलों का वास्तविक आकार छोटा दिखता है। आप "ls -alsh" का उपयोग कर सकते हैं ताकि आकार अधिक पठनीय हो।

तो डेटा फ़ाइल का आकार लगभग 79MB और मेटाडेटा फ़ाइल का आकार लगभग 202KB है।

मुझे लगता है कि किसी भी तरह से उपयोग किए जाने वाले ब्लॉक के बारे में पतले पूल के आंकड़े सही नहीं लगते हैं। क्या मशीन का रिबूट समस्या को ठीक करता है?

मैंने सफलता के बिना कर्नेल अपडेट के बाद एक रिबूट किया।

ठीक है, इसलिए लूप फाइलें बड़ी हैं और पूल को लगता है कि इसमें बहुत सारे उपयोग किए गए ब्लॉक हैं। तो कुछ उन ब्लॉकों का उपयोग कर रहा है। क्या आप मुझे आउटपुट दे सकते हैं

• docker ps -a
• डॉकटर चित्र
• ls / var / lib / dokcer / devicemapper / मेटाडाटा / | wc -l
• शटडाउन docker और निम्नलिखित का पालन करें।
  thin_dump / var / lib / docker / devicemapper / devicemapper / मेटाडेटा | grep "डिवाइस dev_id" | wc -l

इससे पता चलेगा कि पूल में कितने पतले उपकरण हैं।

हम्म,
अब हम डीईएड कंटेनरों को खोदते हैं लेकिन कोई चित्र नहीं।
पहले ही रिबूट कर दिया।

डेविमेपर के साथ कुछ गड़बड़ लगता है।
मैं इस मुद्दे को स्पैम नहीं करना चाहता।
मैं "rm -f / var / lib / docker" भी कर सकता हूं और अपने कंटेनरों का पुनर्निर्माण कर सकता हूं। सब कुछ स्क्रिप्टेड है।

"dmsetup स्थिति"

ऐसा लगता है कि पूल खराब स्थिति में है और सबसे अधिक संभावना है कि इसकी मरम्मत की जरूरत है।

नमस्ते,

मुझे लगता है कि Ubuntu 14.04 के तहत एक ही समस्या थी। हालांकि कारण जहां अवांछित मात्रा (cf. ब्लॉग http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/)। आज्ञा चलाना

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

डिस्क स्थान का एक बहुत जारी किया।

यह किसी भी सार्थक तरीके से तय नहीं है। पूरी तरह से अप-टू-डेट उबंटू 14.04.x ​​इंस्टॉलेशन (नवीनतम एलटीएस रिलीज़) और डॉकर के नवीनतम संस्करण ( $ wget -qO- https://get.docker.com/ | sh माध्यम से स्थापित) के साथ, डॉकर लगातार रीक्लेम करने के लिए कोई आसान तरीका के साथ अंतरिक्ष रिसाव करेगा। docker stop $(docker ps -q) && docker rm $(docker ps -q -a) && docker rmi $(docker images -q) केवल अंतरिक्ष की एक छोटी राशि जारी करता है।

सभी हैक को पुनः प्राप्त करने का एकमात्र तरीका निम्नलिखित हैक है:

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

फिर आपको किसी भी चित्र को फिर से खींचने की आवश्यकता होती है।

@bkeroackdsc वह स्थान "अनाथ" संस्करणों से भी संबंधित हो सकता है?

मैं @bkeroackdsc से सहमत
मैंने @rhvgoyal से पूछा कि वह इस केस को इतना बंद क्यों करना चाहते हैं।
अंत में, मैं इस मुद्दे के कारण विशेष रूप से डॉकटर से गिरा दिया।
यह इस उत्पाद को मार रहा है।

अनाथ या नहीं अनाथ, अंतरिक्ष को साफ करने का कोई अच्छा, आसान, तरीका नहीं है।
क्लीनअप के लिए एक docker cli ऑप्शन होना चाहिए, एक अच्छी स्टेटस रिपोर्ट cli ऑप्शन और कुछ डिसकस मॉनिटरिंग के लिए।

@bkeroackdsc @sagiegurari

कारण मैं पूछ रहा हूँ कि अनाथ संस्करणों इस मुद्दे से संबंधित नहीं हैं,
संबंधित नहीं है devicemapper

अनाथ संस्करणों एक बग नहीं है , लेकिन एक गलत धारणा है कि परिभाषित संस्करणों
एक कंटेनर के लिए स्वचालित रूप से हटा दिया जाता है जब कंटेनर हटा दिया जाता है।
यह _not_ मामला (और डिज़ाइन द्वारा) है, क्योंकि वॉल्यूम में डेटा हो सकता है
कंटेनर के हटने के बाद वह बना रहना चाहिए।

_ कंटेनर के साथ एक वॉल्यूम हटाएं, docker rm -v [mycontainer] ।
वॉल्यूम प्रबंधन कार्य जोड़े जाएंगे (देखें https://github.com/docker/docker/pull/14242 और https://github.com/docker/docker/issues/8363),
और आपको "अनाथ" संस्करणों का प्रबंधन करने की अनुमति देगा।

/var/lib/docker बढ़ते आकार का संकेत नहीं होना चाहिए
उस डेवकेमपर डेटा लीक हो रहा है, क्योंकि उस निर्देशिका के आकार में वृद्धि हो रही है
(अनाथ) संस्करणों का परिणाम भी हो सकता है जिन्हें साफ नहीं किया गया है
उपयोगकर्ता द्वारा (docker उस पथ में अपना सारा डेटा संग्रहीत करता है)।

मुझे वास्तव में उम्मीद है कि वे 2 आइटम आवश्यक क्षमताएं देंगे।
मैं दूसरी वस्तु को समझता था, लेकिन पहला (# 14242), शीर्ष पर यह नहीं समझाता है कि यह इसके अलावा क्या है इसके वॉल्यूम एफ़ी (मतलब, निश्चित नहीं है कि यह क्या क्षमता देता है)।

@sagiegurari यह छवि मात्रा प्रबंधन को लागू करने की आवश्यकताओं का हिस्सा है (कुछ अन्य खुले पीआर के मुद्दे हैं)। अंतिम लक्ष्य डॉकियर में संस्करणों को प्रथम श्रेणी का नागरिक बनाना है, जो उन कंटेनरों के अलग / हटाए / प्रबंधन किए जा सकते हैं जो उनका उपयोग करते हैं।

@swachter उस वर्कअराउंड को पोस्ट करने के लिए धन्यवाद, मैंने उपरोक्त छवि के साथ 6GB पुनः प्राप्त किया।

हमने एक गंदे हैक के साथ टपका हुआ मात्रा का मुद्दा तय किया, क्योंकि यह डॉक डेमॉन को हमारे उच्च-मंथन डॉकर्स मेजबानों पर सेवा समाप्त होने से पहले शुरू करने से रोक रहा था:

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

जो प्री-कैश्ड छवियों को फ्लश किए बिना समस्या को ठीक करता है।

क्या हम एक अलग मुद्दे में टपकी मात्रा के मुद्दे पर चर्चा कर सकते हैं। यहाँ इस पर चर्चा करने से यह आभास होता है कि यह एक डिवाइस मैपर मुद्दा है जबकि ऐसा नहीं है।

@tomlux @rhvgoyal

क्या आप कभी सैंटोस 7 बॉक्स में होने वाले एक निष्कर्ष पर आए थे? मेरा डॉकटर होस्ट लगभग समान है, और मैं एक ही मुद्दे का अनुभव कर रहा था। मैंने उस बिंदु का अनुसरण किया जिसमें thin_dump कमांड चलाने के लिए कहा। के बाद, मैं डॉक डेमॉन को शुरू करने के लिए गया और यह शुरू नहीं होगा। मैंने अभी-अभी / var / lib / docker को डिलीट किया है और तब से रीस्टार्ट किया गया है, लेकिन मैं सिर्फ यह जानना चाहता था कि क्या कोई रिज़ॉल्यूशन मुझे (साथ ही साथ अन्य) भी मिला या नहीं।

[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

मुझे अपने मुद्दे का स्रोत मिल गया। यह दिखाई देने के बावजूद, थ्रेड में मुद्दों से संबंधित नहीं था। यह सिर्फ गलतफहमी से उपजा है कि कैसे काम करता है। सभी, मृत कंटेनर अभी भी डिस्क स्थान पर पकड़े हुए थे जो उन्होंने अपने निष्पादन के दौरान आवंटित किया था। मुझे बस डिस्क स्थान खाली करने के लिए सभी कंटेनर शवों को निकालना था। मुझे याद है कि यह इस धागे में आ रहा है, लेकिन मुझे लगा कि केवल घुड़सवार वॉल्यूम माना जाता है, कंटेनर द्वारा आवंटित डिस्क स्थान नहीं।

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

@tomlux यह आपके docker ps -a कई आउटपुट Dead कंटेनरों को दिखाने के बाद से आपका मुद्दा हो सकता है।

docker rm कंटेनर की डिस्क स्थान को मुक्त नहीं कर रहा है

OS2 VirtualBox में हाल ही में boot2docker। ओएस एक्स पूरी तरह से पैच।

मैं एक फैट (47 जीबी) कंटेनर का निर्माण कर रहा हूं और इसमें एक समस्या है जो यह संकेत देती है कि मुझे कंटेनर का पुनर्निर्माण करना चाहिए। इसलिए मैंने कंटेनर को रोक दिया और डॉकटर आरएम किया। Docker ssh का उपयोग करते हुए डबल-चेकिंग'df -h', मुझे लगता है कि डिस्क का उपयोग अभी भी 47 जीबी है। कंटेनर में 75 जीबी है।

तो मैं फिर से डॉक वीएम को मारने की जरूरत है।

क्या हम यह कर सकते हैं?

@ awolfe-silversky है डिस्क-स्पेस _inside_ VM लौटा? यदि यह VM के बाहर है, तो यह असंबंधित हो सकता है।

@ वोल्फ-सिल्वरस्की भी; आपने _image_ को भी हटा दिया? यदि छवि अभी भी है तो सिर्फ कंटेनर को हटाने से बहुत मदद नहीं मिल सकती है

@ awolfe-silversky यह मुद्दा devicemapper के बारे में है - और यदि आप docker-machine / boot2docker का उपयोग कर रहे हैं, तो आपको aufs चलने की बहुत अधिक संभावना है। मुझे आश्चर्य है कि अगर आपने docker rmi 'अपनी बड़ी छवि बना ली है।

इसकी कीमत docker images , और docker info यह देखने के लिए है कि क्या चीजें वास्तव में उतनी ही भयानक हैं जितनी आप ध्वनि करते हैं :)

(हां, यदि आपके पास अभी भी वीएम है, और छवि हटा दी गई है, तो हमें एक नया मुद्दा खोलना चाहिए और आगे डीबग करना चाहिए, जैसा कि आपने एक अजीब कोने का मामला पाया है)

मैंने प्रतिमा नहीं निकाली। यह आंतरिक डॉकटर रजिस्ट्री से है।
मैंने छवियों को आकार देने के लिए एक अजीब स्क्रिप्ट का उपयोग किया - कुल 6.9 जीबी।

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

यह गंदा है लेकिन मुझे पता है कि सभी छवि आकार MB में हैं।

यहां बताया गया है कि मैं कैसे उपयोग का निदान करने की कोशिश कर रहा था:

 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

अभी मेरे पास 0 चित्र वाले बॉक्स हैं।
docker volume ls -qf dangling=true कुछ भी नहीं दिखाता है।
docker volume ls बहुत सारे वॉल्यूम दिखाते हैं, जो कि परिभाषा के अनुसार, अनाथ हैं, क्योंकि उनके स्वयं के कोई चित्र नहीं हैं।
docker volume rm $(docker volume ls) ऐसे संदेशों से बहुत कुछ पता चलता है:

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

डिवाइस मैपर निर्देशिका 30 GiG खाती है।
डॉकर संस्करण 1.10.2, c3959b1 का निर्माण करें
सेंटोस 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)

इसके अलावा, डिफ़ॉल्ट इंस्टॉलेशन 'दृढ़ता से हतोत्साहित' भंडारण विकल्प का उपयोग क्यों करता है?
मुझे स्थापना पर ऐसा क्यों नहीं बताया गया?

मुझे यहाँ 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

ऐसे उदाहरणों पर, जहाँ मैं नियमित रूप से नए डॉकटर चित्र स्थापित करता हूँ, एकमात्र उपाय निम्नलिखित कार्य करना है:

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

मुझे नहीं लगता कि उत्पादन के माहौल में ऐसी कोई बात स्वीकार्य है

कुछ अतिरिक्त जानकारी:

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

जैसा कि यह बग वर्षों से है और ऐसा लगता है कि अभी तक बंद नहीं हुआ है, क्या आप डीडम डैप के दस्तावेज में डाल सकते हैं कि सुरक्षा को कैसे नष्ट करें?
मेरा मतलब है, इस पृष्ठ में: https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
"सफाई उपकरण मैपर" और इसे कैसे करना है जैसे कुछ डालें।

मैं rm -rf / var / lib / docker करने की कोशिश करूँगा लेकिन मुझे ऐसा करने में कोई परेशानी नहीं है। क्या कोई मुझे बता सकता है कि क्या सुरक्षित है?

मैं अपने दैनिक लैपटॉप में जेंटू लाइनक्स का उपयोग कर रहा हूं और मैंने सीखने के लिए डॉकटर की कोशिश की है, लेकिन मेरी डिस्क को भर रहा है और पूरी प्रणाली को पुनर्स्थापित करना एक विकल्प नहीं है क्योंकि एक वीएम नहीं है और जेंटो को पुनर्स्थापित करने में समय लगता है।

तुम्हारे काम के लिए धन्यवाद।

@mercuriete अपने देव मशीन पर सिर्फ

@ ir- ईंधन: मैंने अभी-अभी ऐसा किया है और अब मेरे पास यह है:

$ 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

मैं service docker start का उपयोग कर रहा हूं

@ ir- ईंधन धन्यवाद, यह ठीक काम करता है। : +1:

डिस्क स्थान को जारी करने के लिए डॉकटर को फिर से स्थापित करना सबसे हास्यास्पद जवाब है जो मुझे इस मुद्दे के समाधान की तलाश में आया था। इतना ही नहीं यह समय की बर्बादी है, अधिकांश वातावरणों में इसकी अनुमति नहीं है। यदि आप एक प्रति घंटा कर्मचारी हैं तो भुगतान करने का यह एक अच्छा तरीका है।

मैं पूरी तरह से सहमत। यह आश्चर्यजनक है कि डॉकर जैसा उत्पाद सिर्फ डिस्क स्पेस को खाने से दूर रखता है, इसके अलावा आप इसे अनइंस्टॉल / रीइंस्टॉल करने के अलावा कुछ नहीं कर सकते।

इस मुद्दे की जाँच अभी तक देखने के लिए कुछ भी नहीं बदला है। +1

यह समस्या बंद चिह्नित है। हमें एक संकल्प की आवश्यकता है। कोई वर्कअराउंड, कोई पुनर्निधारण नहीं। वास्तविक स्थिति क्या है, और कॉन्फ़िगरेशन सेटिंग्स क्या हैं जो फंसाए गए हैं? उत्पादन को ड्राप करना और फिर से बनाना डॉकटर नोड स्वीकार्य नहीं है।

और विकल्प क्या है? हम इससे कैसे बचेंगे?

यदि यह उपयोग करने के लिए अनुशंसित सुविधा नहीं है - यह चुप और डिफ़ॉल्ट क्यों है
एक? यदि आप devicemapper का उपयोग करने वाले लोगों की परवाह नहीं करते हैं - तो मैं ठीक भी हो सकता हूं
इसके साथ। लेकिन उपयोगकर्ता को इसके बारे में सूचित करें! क्या आपको इसकी मात्रा का एहसास है
सिरदर्द लोगों को इस अद्भुत 'वर्कअराउंड' के कारण होता है, जो आपने तय किया था ??
23 जून 2016 को 4:32 बजे, "kpande" सूचनाएं @github.com ने लिखा:

कर्कर डिवाइस-मैपर ड्राइवर का उपयोग करने से बचने के लिए,
दुर्भाग्य से।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/docker/docker/issues/3182#issuecomment -228068397, या म्यूट
सूत्र
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
।

वहाँ हमेशा rkt है ...

सामान्य कुत्सित अपवित्र सांप कोई संदेह नहीं है कि कोई भी क्यों नहीं अपस्ट्रीम से आपको उचित जवाब देने के लिए परवाह करता है।

किसी ने आपको डॉकर का उपयोग करने के लिए मजबूर नहीं किया।

यह ओरेकल एक जावा डेवलपर को जेवीएम बग के कारण PHP का उपयोग करने के लिए कह रहा है। यह भी यहाँ लिफ्ट पिच के अनुरूप नहीं

तीन साल पहले, डॉकर ने एक गूढ़ लिनक्स कर्नेल तकनीक बनाई, जिसे कंटेनरीकरण सरल और सभी के लिए सुलभ बताया।

मुझे यकीन है कि बहुत से लोग आभारी हैं कि डॉकटर ने इसे बंद कर दिया और ऐसा समुदाय के स्वयंसेवा के बिना नहीं हुआ। हालांकि, यह स्वीकार करना कठिन नहीं होना चाहिए कि "जब मैं एक अपस्ट्रीम योगदानकर्ता हूं, तो शट अप और सुने हुए" लाइन को बिना किसी अनपेक्षित बिंदु के लाने के लिए यह समस्या है।

रुको। मैंने एक समस्या की रिपोर्ट की, मेरी मशीन और सेटअप का विवरण प्रदान किया,
जिसके लिए मैं बाध्य नहीं हूं। मेरे और अन्य लोगों को किसी भी भक्त ने जवाब नहीं दिया
आधे साल की अवधि में रिपोर्ट। अब मैंने इस तथ्य को कहा, आप मेरे व्यवहार को कहते हैं
मादा? क्या आप भी ओपन-सोर्स हैं? मुझे काम करने के लिए गो प्रोजेक्ट की तलाश है, और
यह डॉकर नहीं होगा, मैं आपको देता हूं। क्या यह आपका लक्ष्य है?
23 जून 2016 को 16:45, " ग्रेगरी ग्रे"

यदि यह उपयोग करने के लिए अनुशंसित सुविधा नहीं है - यह चुप और डिफ़ॉल्ट क्यों है
एक? यदि आप devicemapper का उपयोग करने वाले लोगों की परवाह नहीं करते हैं - तो मैं ठीक भी हो सकता हूं
इसके साथ। लेकिन उपयोगकर्ता को इसके बारे में सूचित करें! क्या आपको इसकी मात्रा का एहसास है
सिरदर्द लोगों को इस अद्भुत 'वर्कअराउंड' के कारण होता है, जो आपने तय किया था ??
23 जून 2016 को 4:32 बजे, "kpande" सूचनाएं @github.com ने लिखा:

कर्कर डिवाइस-मैपर ड्राइवर का उपयोग करने से बचने के लिए,
दुर्भाग्य से।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/docker/docker/issues/3182#issuecomment -228068393,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
।

सबसे पहले, अगर आपको अभी भी यह समस्या है, तो कृपया एक नया मुद्दा खोलें;

रुको। मैंने एक मुद्दे की सूचना दी

आपने 3 साल पुराने, बंद मुद्दे पर जवाब दिया; ऊपर चर्चा के बाद, मूल मुद्दा हल हो गया था। आपका मुद्दा _may_ समान होना चाहिए, लेकिन यह सुनिश्चित करने के लिए अधिक शोध की आवश्यकता है; आप जिन त्रुटियों को दोहरा रहे हैं, वे संकेत करते हैं कि यह वास्तव में कुछ और हो सकता है।

मैं वास्तव में एक नए मुद्दे को खोलने की सलाह देता हूं, एक बंद मुद्दे पर टिप्पणी नहीं करता

मेरी मशीन और सेटअप का विवरण, जो मैं करने के लिए बाध्य नहीं हूं।

आप _obliged_ नहीं हैं, लेकिन जाने के लिए किसी भी जानकारी के बिना, यह हल होने की संभावना नहीं है। इसलिए, बग की रिपोर्ट करते समय, कृपया टेम्पलेट में पूछी गई जानकारी को शामिल करें:
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

डेढ़ साल की अवधि में मेरी और अन्य लोगों की बग रिपोर्ट का किसी ने भी जवाब नहीं दिया।

यदि आपका मतलब "एक अनुरक्षक" है, तो कृपया ध्यान रखें कि लगभग 24000 मुद्दे और पीआर हैं, और 20 से कम अनुरक्षक हैं , जिनमें से कई अपने दैनिक कार्य के अलावा ऐसा कर रहे हैं। प्रत्येक टिप्पणी को विशेष रूप से देखा नहीं जाएगा यदि यह एक बंद मुद्दे पर है।

यदि यह उपयोग करने के लिए अनुशंसित सुविधा नहीं है - यह चुप और डिफ़ॉल्ट क्यों है?

यह डिफ़ॉल्ट है अगर _aufs_, _btrfs_, और _zfs_ समर्थित नहीं हैं, तो आप उन प्राथमिकताओं को पा सकते हैं जो ड्राइवरों का चयन करते समय उपयोग की जाती हैं; डेमॉन / ग्राफड्राइवर / ड्राइवर_लिनक्स.गो देखें । यह अभी भी उपरिशायी से ऊपर है, क्योंकि दुर्भाग्य से उस ड्राइवर के साथ कुछ शेष समस्याएं हैं जिससे _some_ लोग प्रभावित हो सकते हैं।

स्वचालित रूप से एक ग्राफड्राइवर का चयन करना "चीजों को चलाने के लिए" है; _your_ स्थिति के लिए सबसे अच्छा ड्राइवर _your_ उपयोग-केस पर निर्भर करता है। डॉकर उस निर्णय को स्वचालित रूप से नहीं कर सकता है, इसलिए यह उपयोगकर्ता को कॉन्फ़िगर करने के लिए है।

यदि आप devicemapper का उपयोग करने वाले लोगों की परवाह नहीं करते हैं - मैं इसके साथ ठीक भी हो सकता हूं।

ऊपर चर्चा को वापस पढ़ते हुए, मैं देखता हूं कि अपस्ट्रीम डेविसेमर के रख-रखावकर्ताओं ने इस _multple times_ को देखा है, जो इन मुद्दों की रिपोर्टिंग करने वाले उपयोगकर्ताओं की सहायता करने की कोशिश कर रहा है, और समस्या का समाधान कर रहा है। इस समस्या को उन लोगों के लिए हल किया गया था जिन्होंने इसे रिपोर्ट किया था, या कुछ मामलों में, डिवोर्स को अद्यतन करने पर निर्भर थे। मुझे नहीं लगता कि इसे "देखभाल नहीं" माना जा सकता है।

इसके अलावा, डिफ़ॉल्ट इंस्टॉलेशन 'दृढ़ता से हतोत्साहित' भंडारण विकल्प का उपयोग क्यों करता है?

लूप डिवाइसेस पर चलना डॉक चलाने के लिए ठीक है, और वर्तमान में स्वचालित रूप से डेविक्मेपर स्थापित करने का एकमात्र तरीका है। उत्पादन के लिए, और कुल मिलाकर एक बेहतर प्रदर्शन प्राप्त करने के लिए, डायरेक्ट-एलवीएम का उपयोग करें, जैसा कि स्टोरेज ड्राइवर उपयोगकर्ता गाइड में डेविक्मेपर सेक्शन में बताया गया है।

मुझे स्थापना पर ऐसा क्यों नहीं बताया गया?

यह वास्तव में स्थापना के लिए गुंजाइश से बाहर है। यदि आप उत्पादन में कुछ सॉफ़्टवेयर का उपयोग करने जा रहे हैं, तो यह मान लेना उचित होगा कि आप स्वयं को उस सॉफ़्टवेयर से परिचित कराते हैं, और जानते हैं कि इसे आपके उपयोग के मामले में सेट करने के लिए क्या आवश्यक है। कुछ मेंटेनर्स ने यह भी तर्क दिया कि अगर चेतावनी बिल्कुल आउटपुट होनी चाहिए। लिनक्स एक "हाथ पकड़े हुए" ओएस नहीं है (क्या आपके डिस्ट्रो ने चेतावनी दी है कि यदि आप RAID-0 का उपयोग कर रहे हैं तो डेटा हानि हो सकती है? यदि आपके पोर्ट फायरवॉल में खोले गए हैं?)

जैसा कि मैं इस प्राचीन सूत्र को फिर से जीवित करता हूं, मैं एक बार फिर से इस समस्या से जूझने वाली मौजूदा मशीन पर इस मुद्दे के आसपास काम करने के बारे में कोई सार्थक सलाह नहीं देता।

यह एक tldr पर मेरा सबसे अच्छा प्रयास है; पूरे धागे के लिए; मुझे आशा है कि यह इस धागे को खोजने वाले अन्य लोगों की मदद करता है।

मुद्दा सामने आया

आपके वॉल्यूम में अंतरिक्ष की एक महत्वपूर्ण (और बढ़ती) राशि है जो /var/lib/docker और आप ext3 का उपयोग कर रहे हैं।

संकल्प

तुम अभागे हो। अपने फ़ाइल सिस्टम को अपग्रेड करें या नीचे blowing docker away ।

मुद्दा सामने आया

आपके वॉल्यूम में अंतरिक्ष की एक महत्वपूर्ण (और बढ़ती) राशि है जो /var/lib/docker और आप _not_ 3 (जैसे वर्तमान में xfs या ext4 का उपयोग कर सिस्टम) का उपयोग कर रहे हैं।

संकल्प

आप मानक डॉकटर कमांड का उपयोग करके अपने डिवाइस पर स्थान को पुनः प्राप्त करने में सक्षम हो सकते हैं।

Http://blog.yohanliyanage.com/2015/05/docker-clean-up-after-yourself/ पढ़ें

ये आदेश चलाएँ:

docker volume ls
docker ps
docker images

यदि आपके पास इनमें से कुछ भी सूचीबद्ध नहीं है, तो नीचे blowing docker away देखें।

यदि आपको पुरानी बासी छवियां, अप्रयुक्त कंटेनर आदि दिखाई देते हैं, तो आप मैन्युअल सफाई कर सकते हैं:

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

यह डेविक्मेपर में छिपे हुए कंटेनर के अधिकांश भाग को पुनः प्राप्त करना चाहिए।

उड़ाने वाला काम करने वाला

काम नहीं किया? तुम अभागे हो।

इस बिंदु पर आपकी सबसे अच्छी शर्त है:

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

यह आपके सभी डॉकरों की छवियों को नष्ट कर देगा। उन लोगों को निर्यात करना सुनिश्चित करें जिन्हें आप ऐसा करना चाहते हैं।

अंततः, कृपया https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-production पढ़ें; लेकिन मुझे उम्मीद है कि यह इस धागे को खोजने वाले अन्य लोगों की सहायता करेगा।

यदि आपको ऊपर दिए गए सलाह का उपयोग करने में परेशानी होती है, तो एक नया टिकट खोलें जो विशेष रूप से आपके द्वारा सामना की जाने वाली समस्या का समाधान करता है और इस मुद्दे को लिंक करता है; इसे यहां पोस्ट न करें।

rm -rf / var / lib / docker

आप nuke-graph-directory.sh का भी उपयोग कर सकते हैं।

ऊपर बताई गई फाइलों को हटाने के बाद, मैं डॉकर को शुरू नहीं कर सकता:
मार्च 02 04:53:40 pmdc001b dockerd [29522]: डेमॉन शुरू करने में त्रुटि: ग्राफड्राइवर को आरम्भ करने में त्रुटि: खुला / var / lib / docker / devicemapper / devicemapper / data: आपके पास ऐसी कोई फ़ाइल या निर्देशिका नहीं है

बस CentOS 7.3 पर इस मुद्दे में भाग गया और 3 से अधिक वर्षों के लिए मौजूद devmapper मुद्दों को डिबग नहीं करना चाहता था, इसलिए मैंने इस डीसी / ओएस गाइड का पालन किया, मूल पैकेजों को शुद्ध किया, ओवरलेफ़्स पर स्विच किया और अब सब कुछ ठीक काम करने लगता है : https://dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/ (docker संस्करण 17.03 के लिए ExecStart कमांड को संशोधित करना था हालांकि>> "dockerd --storage- ड्राइवर = ओवरले ")

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

(पर्सिंग वॉल्यूम, चित्र और कंटेनर मदद नहीं करते थे / @ gdring2 द्वारा वर्णित समस्या के कारण / var / lib /

docker system prune चलने से मेरी मशीनों पर बहुत अधिक स्थान खाली हो गया।

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

खैर, यह एक तरह से है ... लंगड़ा।

मेरे मामले में मुझे यह समस्या मिली जब मैंने डॉकर की स्थापना रद्द कर दी और /var/lib/docker निर्देशिका को हटा दिया, इसलिए मैं service docker stop ... service docker start के बराबर नहीं चला सका।

मैंने पाया कि मेरा सिस्टम /var/lib/docker को हटाने से अंतरिक्ष की रिपोर्ट नहीं कर रहा था (मुझे ~ 14 GB जो कि लाइमबो की तरह लग रहा था) में बैठे थे।

इसे ठीक करने के लिए बस आपकी फ़ाइल प्रणाली को फिर से लोड करना है, मेरे मामले में मुझे बस रिबूट किया गया और अंतरिक्ष को पुनः प्राप्त किया गया।

मुझे विश्वास नहीं हो रहा है कि यह अभी भी एक मुद्दा है! दोस्तों चलो, मैं अभी भी कर रहा हूँ

@ shahaf600 आप किस संस्करण में काम कर रहे हैं? ऊपर मेरी टिप्पणी भी देखें; https://github.com/moby/moby/issues/3182#issuecomment -228298975

विवरण के बिना आपकी स्थिति के बारे में कहने के लिए बहुत कुछ नहीं है; आपका मामला एक अलग मुद्दे के कारण हो सकता है, लेकिन एक समान परिणाम के रूप में।

अच्छा

कचरे के इन टुकड़ों में से एक को खरीदने और समर्थन की स्थिति देखने के बाद, मैंने इसे वापस कर दिया।

आपकी पहली समस्या @misterbigstuff है ... आपने कुछ खरीदा है जो खुला स्रोत है?

और उसे वापस कर दिया