+1 ، أنا مهتم جدًا بسماع بعض المناقشات حول هذا الموضوع. كانت استراتيجيتي حتى الآن

• كن حذرا مما تبنيه / تسحب
• كن مستعدًا لتفجير / var / lib / docker: natural_face:

AaronFriel ، ما هو إصدار Docker الذي تستخدمه؟ 0.7.1؟

/ ccregilero (الرابط أيضًا في # 2276)

بدءًا من ملف جديد / var / lib / عامل إرساء:

# 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

ثم بعد سحب عامل الإرساء BUSYBOX نما قليلاً:

# 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 _not_ يجعل الملف أكبر ، لكنه يجعل المساحة خالية في تجمع devicemapper:

# ls -lsh /var/lib/docker/devicemapper/devicemapper/*
298M -rw-------. 1 root root 100G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/data
4.0K -rw-------. 1 root root   89 Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/json
772K -rw-------. 1 root root 2.0G Dec 12 17:32 /var/lib/docker/devicemapper/devicemapper/metadata
# docker info
Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-0:31-15888696-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb

لا ينمو ملف الاسترجاع إذا قمنا بتنزيل الصورة مرة أخرى:

# 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 image ، فإنه _does_ يستعيد المساحة الموجودة في ملف الاسترجاع.
أي فعلت هذا في صورة 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

أدى ذلك إلى زيادة حجم ملف البيانات من 299 مليونًا إلى 344 مليونًا. لكن عندما أزلت a_file.bin (وانتظرت قليلاً) ، عاد إلى 299 مليونًا.

لذلك ، يبدو لي أن هذا خطأ في جهاز رسم الخرائط. أي أنه يعيد توجيه المهملات من الجهاز الرقيق إلى الجهاز الأساسي ، لكنه لا يتجاهل عند إزالة الأجهزة الرقيقة من التجمع.

يبدو أن هذه مشكلة في kernel ، كنت أبحث في حلها باستخدام BLKDISCARD ، لكنني فشلت. راجع هذه الأخطاء للحصول على بعض التفاصيل: https://bugzilla.redhat.com/show_bug.cgi؟id=1043527

أضع الحل البديل في https://github.com/alexlarsson/docker/tree/blkdiscard ، لكننا ما زلنا نبحث عما إذا كان بإمكاننا أن نفعل أفضل من ذلك.

تعليقات المنبع DM على هذه المسألة:
http://device-mapper.org/blog/2013/12/17/thin-provisioning-and-discard-support/

وجود هذه المشكلة على CentOS (2.6.32-358.23.2.el6.x86_64) مع Docker 0.7.0 أيضًا. قديم ، لكن المشكلة ليست معزولة عن أوبونتو.

نفس المشكلة على Arch GNU / Linux 3.12.6-1-ARCH ، إصدار Docker 0.7.2.

لا يزال موجودًا عند 0.7.0 في CentOS.

لا يزال موجودًا في 0.7.2 على ubuntu 12.04.3 LTS.

الكثير من المساحة في docker/devicemapper/devicemapper/data و metadata ، ولكن أيضًا في docker/devicemapper/mnt

لقد علمت أنه يمكنك رؤية أنظمة ملفات الحاوية في docker/devicemapper/mnt/SOME_KIND_OF_ID/rootfs

ولكن ليس من الرائع أن يتم التهام قرصي الصلب بالكامل تقريبًا ولا يمكن إصلاحه إلا بمقدار rmdir -r docker .

أواجه مشكلة مماثلة أثناء كتابة دعم عامل الإرساء لنظام rspec. يحتوي جهاز VM التجريبي (مضيف عامل الإرساء) على محرك سعة 8 جيجابايت وبعد إنشاء الصور بشكل متكرر دون حذفها ، يمتلئ محرك الأقراص. ولكن بعد إزالة جميع الصور والحاويات ، يظل محرك الأقراص ممتلئًا بنسبة 100٪. اعتقدت أنه كان خطأ ID-10T لكنني استسلمت للتو ودمرت الجهاز الظاهري معًا.

لا يزال موجودًا في 0.7.5 على أوبونتو 13.04.

تم إصلاح هذه المشكلة عن طريق PR # 3256 الذي تم دمجه مؤخرًا. سيتم تضمين هذا الإصلاح في إصدار مستقبلي.

أقوم بإغلاق هذه المشكلة الآن لأنه تم دمج الإصلاح الرئيسي.

ملحوظة: لم يتم إصلاحه بالكامل حتى تقوم بتشغيل نواة مع http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/؟h=for-next&id= 6d03f6ac888f2cfc9c840db0b965436d32f1816d فيه. بدون ذلك يكون إصلاح عامل الإرساء جزئيًا فقط.

ما هو العمل حول إزالة الفضاء. أنا أستخدم rhel 6.5 وقد يستغرق الأمر بعض الوقت للحصول على النواة الجديدة.

مرسل من الايفون الخاص بي

في 21 كانون الثاني (يناير) 2014 ، الساعة 6:18 صباحًا ، كتب ألكسندر لارسون [email protected] :

ملاحظة: لم يتم إصلاحه بالكامل حتى تقوم أيضًا بتشغيل نواة مع http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/؟h=for-next&id= 6d03f6ac888f2cfc9c840db0b965436d32f1816d فيه. بدون ذلك يكون إصلاح عامل الإرساء جزئيًا فقط.

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub.

logicminds لا توجد طريقة فائقة السهولة لاستعادة مساحة أجهزة الصراف الآلي. من الناحية الفنية ، يجب أن يكون من الممكن إعادة توزيع ملفات الاسترجاع يدويًا. لكن هذا يتطلب صفراً لجميع الكتل غير المستخدمة أو شيء ما للكشف بسهولة عن المناطق المتفرقة ، وهو ما لا يتم في إزالة الجهاز الرقيق.

alexlarsson هل يؤثر هذا أيضًا على OEL 6.5؟ يستخدم OEL 6.5 في الواقع نواة uek 3.8 linux وبما أن لدي الخيار بين التبديل من 2.6 إلى 3.8 kernel ، فقد يكون هذا مفتاحًا بسيطًا بالنسبة لي.

logicminds لا أعرف حتى ما إذا كان هذا الالتزام

أنا أبحث في إنشاء أداة مثل fstrim يمكن استخدامها لاستعادة المساحة.

تم إغلاق إصدار alexlarsson https://bugzilla.redhat.com/show_bug.cgi؟id=1043527 رسميًا بسبب "عدم كفاية البيانات". هل هذا يعني أن التصحيح لن يصل إلى النواة؟ هل ما زالت هناك حاجة؟

vrvolle التصحيح الذي يجعل الحل البديل الذي يستخدمه عامل

ما زلت أواجه هذه المشكلة مع docker 0.9 على centos 6.5 مع الافتراضي 2.6.32 kernel.

لست متأكدًا من فهم ما قلته سابقًا حول هذا الالتزام في مخطط الجهاز. هل يمكنك تأكيد أنه إذا قمت بترحيل kernel الخاص بي إلى 3.8 ، فيجب حل هذا الخطأ؟

شكرا لك مقدما.

@ nicolas-van لا ، أنت بحاجة إلى هذا الالتزام: https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316

إنه في 3.14 ، وقد يكون في مختلف المنافذ الخلفية 3.xy

لقد قمت بتثبيت عامل الإرساء منذ بعض الوقت لإنشاء صورة وتشغيلها داخل حاوية. ثم بعد مرور بعض الوقت ، قمت بمسح جميع الصور والحاويات ، بما في ذلك تطبيق docker والمجلد الرئيسي.
أدرك الآن أنه من إجمالي 4 غيغابايت / 24 غيغابايت مجانًا / مستعملة (df -h) ، يبلغ أمر du / -sh عن 10 غيغابايت فقط لذلك لا يتم حساب 10 غيغابايت أخرى. هذا هو حجم أقل من الصور المؤقتة التي تم إنشاؤها باستخدام عامل الإرساء ، فهل يمكن أن يكون مرتبطًا بهذا الخطأ. لقد استخدمت centos 6.5 و docker 0.9.

لقد قمت بإزالة docker مع yum ، و devs من / dev / mapper / docker * مع dmsetup ، وأيضًا rm / var / lib / docker -Rf ، وما زلت تقارير القرص باستخدام df 10 جيجا بايت التي لا يمكنني العثور عليها في أي مكان.

Jacq من الممكن أن

قمت بتشغيل Linux 3.14.4-1-ARCH ، و docker 0.11.1 ، بإزالة جميع الصور والحاويات.
والملف / var / lib / docker / devicemapper / devicemapper عالق للتو ، ويستهلك حوالي 1.5 جيجابايت

هنا ناتج بعد أن كنت أتلاعب ببعض الأشياء mongodb ، أعتقد أن حجم الملف يجب أن يتم تخصيصه بشكل ضئيل لأن my / 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

عفوا ، هل تم إصلاح الخلل الآن؟ لقد واجهت ذلك في gentoo.

bolasblack أدير gentoo وواجهت هذه المشكلة. هل اكتشفت أي شيء؟

أنا أستخدم أحدث مصادر gentoo وهي 3.14.14 لـ x86_64. نظرت إلى https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316؟diff وتم تطبيق هذا التصحيح على مصادري. لديّ إصدار Docker Docker 1.1.0 ، بناء 79812e3.

alexlarsson نشكرك على إعادة انتباهك إلى هذه المشكلة المغلقة بعد فترة طويلة من الزمن. يبدو أنه لا يزال يسبب المشاكل. أي كلمة عن حالة # 4202؟

وما زالت هذه المسألة! أعتقد أنني سأعود إلى استخدام AUFS في الوقت الحالي.

daniellockard يبدو أن AUFS قد تم إهماله بشكل غير رسمي: # 783 و # 4704 ، حظًا سعيدًا في ذلك.

Yikes ... أين ذهب 25 غيغابايت؟ أوه ، في هذا الملف ... أنا أقوم بتشغيل kernel 3.16.2 f20 64b

الارتباط إلى "الحل البديل" معطل ... ما هو؟ وهل تدعمها النواة الخاصة بي ... إذا التزم Torvalds بـ 3.14 ، أعتقد أن فيدورا يجب أن يراها في 3.16 ، أليس كذلك؟

+1

+1

+1

+1 يبدو أنه لا يزال يحدث على Ubuntu Trusty ، 3.13.0-36-generic مع Docker الإصدار 1.3.1 ، بناء 4e9bbfa

+1 أيضًا على Trusty. هل يستحق التحقق من 14.10 الذي يستخدم 3.16؟

SvenDowideitshykesvieuxalexlarssonZolmeistercreackcrosbymichaeldhrp @ jamtur01tianonerikh @ LK4D4

وضع علامة على كبار الملتزمين لأن هذا أمر سخيف. يجب أن تكون هناك محادثة عامة حول هذا الأمر واعتراف من فريق Docker بأن هذا الخطأ يمكن أن يؤدي إلى حاويات أو أنظمة تتعطل بشكل دوري وتحتاج إلى إعادة إنشائها. أنا أعرف بالفعل العديد من الأشخاص الذين اضطروا إلى تنفيذ حلول devops المجنونة مثل إعادة تصميم مضيفي Docker بشكل دوري كل أسبوع أو أسبوعين لأن روبوتات البناء لديهم الكثير من الاضطراب. لقد قدمت هذه المشكلة منذ ما يقرب من عام مضى ، وكان هناك ، أقرب ما يمكنني قوله ، لم يتم إنشاء حل نهائي ، ولم يتم إنشاء نواة أقدم مدعومة ظاهريًا.

فريق Docker: يرجى إجراء البحث لتحديد إصدارات kernel التي تم تفعيلها ، ولماذا ، وما هو التصحيح الذي سيعمل على حل المشكلة وتوثيقها. انشر هذه المعلومات جنبًا إلى جنب مع إصدارات kernel التي تدعمها ، لأن مستهلكي Docker في الوقت الحالي يتعرضون للعض من هذه المشكلة مرارًا وتكرارًا ، كما يتضح من حقيقة أنني ما زلت أتلقى رسائل بريد إلكتروني حول هذه المشكلة كل أسبوع أو أسبوعين. على محمل الجد ، هذه مشكلة كسر وكانت نقطة ألم منذ ما قبل الإصدار 1.0.

كما أراها ، هناك العديد من الخيارات الممكنة لإصلاح هذه المشكلة بطريقة مرضية من شأنها أن توقف رسائل البريد الإلكتروني التي أستمر في تلقيها من أجل إجراءات 1+ بشأن هذه المشكلة:

1. قم بإعلام المستخدمين عند استخدام Device-Mapper على نواة غير مدعومة وتزويدهم بإرشادات مفصلة حول كيفية استعادة المساحة ، وإذا أمكن ، قم بإعداد عملية تلقائيًا للقيام بذلك في Docker. أنصح بضرورة إصدار هذا الإشعار أيضًا عند استخدام Docker CLI ضد مضيف يعاني من هذه المشكلة ، بحيث عند إدارة المضيفين عن بُعد من Docker CLI ، يتم إعلام المستخدمين بأن بعض المضيفين قد لا يستعيدون المساحة بشكل صحيح.
2. إصلاح المشكلة (بطريقة ما). لا أعرف ما يكفي عن تطوير kernel لأعرف ما سيترتب على ذلك ، لكن بناءً على قراءتي المبتدئة ، أقترح هذا:

أ. نظرًا لأن مخطط الجهاز عبارة عن وحدة نمطية kernel ، قم بإحضار نسخة وظيفية وعملية منه إلى شجرة مصدر Docker كشيء مثل dm-docker

ب. قم بإجراء تغييرات كافية على dm-docker بحيث يمكن أن تتعايش مع مخطط الجهاز.

ج. على الأنظمة الأساسية المتأثرة ، قم بتثبيت وحدة dm-docker kernel عند التثبيت وافتراضيًا لاستخدام dm-docker .

1. قم بتعديل مستندات التثبيت الخاصة بك وموقع docker.com لتضمين تحذير بشأن إصدارات kernel المتأثرة ، وإضافة فحص وقت التشغيل إلى الحزم للتحقق من عملية مخطط الجهاز الصحيحة ، وإذا لم يتم إبلاغ المستخدم بذلك.

يجب أن تكون هذه مشكلة حظر للإصدار المستقر التالي من Docker ، لأنه من غير المقبول ببساطة الاستمرار في التأديب عليه وترك المستخدمين في مأزق.

أنا شخصياً أرى أن CoreOS هو توزيعة Linux الوحيدة المستقرة لـ Docker (حتى يتم حل هذه المشكلة).

فريق Docker: أعلم أن هذه المشكلة ليست بسبب المكون الخاص بك ، ولكن من فضلك ساعدنا في استخدام برنامجك أيضًا على توزيعات Linux الأخرى. سيكون من الجيد إذا كان بإمكانك أيضًا ذكر هذه المشكلة كحد معروف جيدًا لـ Docker في التوثيق ، لذلك لن يضيع الأشخاص الآخرون وقتهم.

شكر!
مارتن

1+ شيء يجب القيام به.

سيكون من الجيد إذا كان هناك شيء أكثر وضوحًا لهذه المشكلة من الاضطرار إلى البحث في قائمة مشكلات github (المغلقة). لقد استغرق الأمر وقتًا طويلاً لاكتشاف أن هذه كانت المشكلة الأساسية وكان من الجيد توضيح هذه المشكلة.

كان لدى مطوري مخطط الأجهزة (أنا وجو ثورنبر) وعيًا تامًا بأن هذه المشكلة لا تزال تمثل مشكلة للناس. لقد أصلحنا المشكلة على الفور بمجرد علمنا بها (بواسطة alexlarsson مرة أخرى في ديسمبر 2013) http://git.kernel.org/linus/19fa1a6756ed9e9 ( "dm thin: إصلاح تجاهل الدعم إلى كتلة تمت مشاركتها مسبقًا")

تم إطلاع جو ثورنبر للتو على أن docker go. عندما أشرت إليه ، تولى تنفيذ أداة "Thin_trim" المستقلة المناسبة والتي سيتم توزيعها كجزء من حزمة "device-mapper-persistent-data" (على الأقل في Fedora ، CentOS ، RHEL) ، انظر:
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

لذا ... كل ما قيل ، يحتاج المستخدمون الذين يشغلون نواة لا تحتوي على نسخ أولية تلتزم 19fa1a6756ed9e9 ("dm thin: إصلاح تجاهل الدعم إلى كتلة تمت مشاركتها مسبقًا") لإصلاح ذلك عن طريق تشغيل نواة مدعومة بشكل أفضل. يمكنني بسهولة إرسال ملاحظة إلى [email protected] لإعادة نواة مستقرة لا تحتوي عليها بالرغم من ذلك. لذا يرجى إعلامي أي نواة (نواة) مستقرة ، إن وجدت ، لا تحتوي على هذا الإصلاح.

من الآن فصاعدًا ، سنريد أن يقوم عامل الإرساء بتشغيل "thin_trim" بشكل دوري ضد جهاز التجمع الرقيق الذي يستخدمه عامل الإرساء. لكننا سنعبر هذا الجسر بمجرد توفر "thin_trim" على نطاق واسع في التوزيعات.

shabbychef @ daniellockard لا ، لم يتم إهمال AUFs - أولاً ، تم إغلاق واحدة فقط من هذه المشكلات ، والقراءة ، أنا أخمن https://github.com/docker/docker/issues/783#issuecomment -38731137 يستحق القراءة:

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. سيحتاج عامل الإرساء الذي يقوم المستخدمون بتشغيله أيضًا إلى تضمين

لمعلوماتك ، سيؤدي تشغيل "أهداف dmsetup" إلى سرد الإصدارات المستهدفة الرقيقة والضعيفة (بشرط تحميل وحدة نواة dm-thin-pool).

شكرا لاهتمامكم على هذا. ذكرنا ذلك إلى رجال الكشك في Re: Invent الأسبوع الماضي.

snitm لذا يجب إضافة dmsetup targets الناتج إلى الناتج check-config ؟

snitm

هل سيكون من الممكن إنشاء اختبار آلي من شأنه إنشاء جهاز مخطط جهاز قليل التزويد ، وإجراء بعض العمليات عليه التي قد تفشل في استعادة مساحة خالية على نواة غير مصححة ، والإبلاغ عن رمز الحالة بناءً على ذلك؟

SvenDowideit هل تأمل في التقاط أي

AaronFriel يبدو أن

وبتراجع خطوة إلى الوراء ، أصبح بمقدوري الاستمتاع بالعمل لدى شركة تتفهم أن المنتجات ذات الطبقات تحتاج إلى التطوير بالتنسيق مع جميع الطبقات الأساسية. ولدي القليل من الاهتمام بدعم التزويد النحيف لـ DM لـ N يتم إقران نواة عشوائية مع عامل الإرساء.

ويصادف أنني أعتقد بقوة أنه لا ينبغي لأحد أن يستخدم التزويد النحيف DM مع أجهزة الاسترجاع كأجهزة دعم. كان هذا اختراقًا كاملاً تم دمجه في عامل الرصيف دون أي قيود أو قلق مناسب بشأن "كيف يبدو هذا في الإنتاج؟".

لقد أدركت أن النشر المناسب لوحدة الإرساء على التزويد الرقيق لـ DM يتطلب ميزات الإدارة الموجهة نحو المؤسسة التي يوفرها تكوين التزويد الرقيق المستند إلى lvm2. لذلك مع وضع ذلك في الاعتبار ، عملت بثبات على عمل حل إدارة مختلط جديد ، راجع هذا العلاقات العامة:
https://github.com/docker/docker/pull/9006

يعتمد هذا العمل على:
1) lvm2> = 2.02.112
2) إصدار DM Thin-pool المستهدف> = v1.14.0 (يُعرف أيضًا باسم التغييرات التي تم إجراؤها في نظام Linux-next لإدراج Linux 3.19)

سيكون لدى RHEL7.1 هذه التغييرات. و RHELAH (المضيف الذري) كذلك. أي توزيعات / منتجات أخرى ترغب في نشر عامل إرساء بشكل صحيح على التزويد الرقيق DM يجب أن يكون كذلك.

snitm نعم - أحاول تقليل عدد المستخدمين الذين أصيبوا بكسر خبيث ، والذي يستغرق وقتًا أطول حتى يدرك شخص ما أنه قد يكون هذا الألم الغامض ، ثم محاولة مطالبة المستخدم باكتشاف ذلك أن عدم وجود رقعة غامضة هي المشكلة.

وبالتالي في سياق المعلومات المتبقية - أريد تقليل عدد النوى التي ستسبب هذه المفاجأة المروعة :)

SvenDowideit حسنًا ، لقد قدمت المعلومات التي يمكن أن يستخدمها عامل الإرساء (أو مستخدميه) للتحقق من توافق DM Thinp على الاسترجاع في هذا التعليق: https://github.com/docker/docker/issues/3182#issuecomment -63706507

snitm ،AaronFriel
أواجه ما يبدو مثل هذه المشكلة على AWS beanstalk ، Amazon AMI.
(تنفد المساحة)
Linux ip-172-31-63-145 3.14.23-22.44.amzn1.x86_64 # 1 SMP الثلاثاء 11 نوفمبر 23:07:48 بالتوقيت العالمي المنسق 2014 x86_64 x86_64 x86_64 GNU / Linux

إصدار عامل ميناء $ sudo
إصدار العميل: 1.3.2
إصدار واجهة برمجة تطبيقات العميل: 1.15.0
إصدار Go (العميل): go1.3.3
Git الالتزام (العميل): c78088f / 1.3.2
OS / Arch (العميل): linux / amd64
إصدار الخادم: 1.3.2
إصدار Server API: 1.15.1
إصدار Go (الخادم): go1.3.3
Git الالتزام (الخادم): c78088f / 1.3.2

ما زلت أتلقى هذا الخطأ مع Ubuntu 14.04 و Docker 1.4.1.

لا تعتمد على أن تكون الإصدارات الرفيعة والنحيفة> = 1.12.0 تعني أنك على ما يرام ، فنحن نشغل CentOS 6.5 VMs مع 2.6.32-431.29.2.el6.x86_64 kernel and dmsetup أهداف تفيد بأن رقيقة البركة ورقيقة كلاهما v1.12.0. ومع ذلك ، فأنا عالق مع ملف بيانات بحجم 40 جيجابايت لا يحرر نفسه.

ما هي الآثار المترتبة على تشغيل هذا على CentOS / RHEL 6.5 مع هذا الخطأ؟ هل أنت موافق مع> = 100G من المساحة الخالية. أفترض أن هذا يملأ في النهاية أي حجم القرص؟ أم أنها مقيدة بـ 100 جرام؟

ضع في اعتبارك أن 6.5 لا يحتوي على أحدث نواة متاحة للسنتوس. أوصي بـ "تحديث yum" بسيط إلى 6.6 وإعادة تشغيل للاختبار باستخدام نواة 2.6.32-504.3.3.

تأكد من أن أحدث تحديثات kernel و distro لـ CentOS 6 تعمل بشكل جيد وتحرر مساحة.

ripienaar: هل يمكنك تحديد إصدار CentOS 6 و kernel الذي تستخدمه؟ أريد فقط التأكد من أنه عندما أمرر المعلومات ، لدي كل المعلومات التي أحتاجها.

شكر.

كما علق reiz أعلاه ، هذا يحدث مع أحدث Ubuntu 14.04 + أحدث عامل تشغيل. تُظهر أهداف dmsetup مجموعة رقيقة / رفيعة من v1.9.0 في إحدى مثيلاتنا (لا توجد حاويات عامل إرساء نشطة.) لا تعرض أهداف dmsetup أي إدخالات رفيعة في مثيل مماثل مع حاويات عامل إرساء نشطة. (أنا لا أطلب المساعدة في هذا الأمر ، فقط أضف بيانات (آمل أن تكون مفيدة).)

عناصر نظام التشغيل الأساسية:

# 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 أن هذا تم حله باستخدام centos kernel 2.6.32-504.3.3. هل من المعروف أي نواة تلتزم (مجموعة الالتزامات؟) التي تحل هذه المشكلة؟

أستخدم حاليًا أحد Oracle Enterprise Linux 3.8 UEK.

هل هناك أي حل بديل لهذا الموقف؟ في AWS من السهل فقط إعادة إنشاء المثيل ولكن في بيئة التطوير المحلية ليس من الجيد ملاحظة أن القسم / var مملوك بنسبة 90٪ من قِبل مصمم الخرائط بسبب عامل الإرساء ؛ قريبًا لن يكون هناك مساحة حتى للسجلات أو المجلات

donrudo على النحو الوارد أعلاه - التحديث إلى أحدث centos 6 - نواة 504.3.3.

لا بأس بذلك بالنسبة للسنتوس ولكن بعض مطورينا يستخدمون Fedora والبعض الآخر OpenSuse.

يتم إرسال جميع تغييرات التوفير النحيف DM أولاً. لذلك إذا تم إصلاح Centos 6 ، فسيتم إصلاحه أيضًا في المنبع. تحتاج التوزيعات المختلفة إلى سحب الإصلاحات للخلف أو إعادة وضعها بشكل أكثر قوة.

ripienaar @ سأسأل مرة أخرى ، هل تعرف أي kernel يلتزم (أو مجموعة الالتزامات) المطلوبة

تضمين التغريدة

أرى هذه المشكلة على Ubuntu 14.04 Trusty and kernel 3.13.0-36-generic. الحل المحتمل هو إرفاق تخزين AWS EBS بالدليل حتى يمكن توسيع نطاقه إلى أجل غير مسمى.

يا رفاق ، هذه القضية مؤلمة حقًا. ينتقل CoreOS إلى ext4 الآن وقريبًا سيكون لدينا كل هذه المشاكل على CoreOS أيضًا.

كيف يمكن للأشخاص استخدام عامل الإرساء (في dev أو prod) أثناء عدم إصلاح هذه المشكلة لأكثر من عام؟ كل شخص لديه أقراص لا نهاية لها؟

أعتقد أنهم ينتقلون إلى ext4 من أجل التراكب وليس devmapper. ولكن ذاك
مجرد كلمة في الشارع ...

يوم الأربعاء ، 28 يناير 2015 ، كتب Sergey [email protected] :

يا رفاق ، هذه القضية مؤلمة حقًا. ينتقل CoreOS إلى ext4 الآن وقريباً نحن
كل هذه المشاكل على CoreOS أيضًا.

كيف يمكن للأشخاص استخدام عامل الإرساء (في dev أو prod) أثناء عدم إصلاح هذه المشكلة
أكثر من سنة؟ كل شخص لديه أقراص لا نهاية لها؟

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/3182#issuecomment -71800923.

أنا حائر. تبلغ مساحة القرص الخاصة بي على مثيل Google 10 جيجا فقط ، ولكن حجم / var / lib / docker / devicemapper / devicemapper / data يظهر على أنه 100 جيجا بايت. لا يمكنني استعادة المساحة حتى بعد حذف جميع الحاويات والصور.

إنه ملف متفرق. استخدم ls -sh بدلاً من ls -l أو بدلًا من du -h

يمكنني الإبلاغ عن هذا على Ubuntu 13.04 (ربما ليس من المستغرب).

هل الحل الحقيقي الوحيد لهذا الآن هو توفير مساحة قرص كافية لتوقع نمو devicemapper؟

هذا الخيط بأكمله سخيف للغاية. يشتكي مستخدم ديبيان واحدًا تلو الآخر. إذا كنت تواجه مشكلة ، فيجب عليك إما التبديل إلى توزيعة يتم صيانتها بشكل صحيح أو العمل مع المشرفين على التوزيعات لحملهم على إصلاح المشكلة. هذه التوزيعات لا تواكب الإصلاحات أو التحسينات. سأتجاهل كل التوسلات المستقبلية لشخص ما لإصلاح هذه المشكلة على distro $ foo نظرًا لأن الإصلاح من الواضح بالفعل في المنبع (انظر CentOS أو RHEL). يرجى فتح خطأ في التوزيعة المعطلة المعنية والإشارة إلى هذه المشكلة.

ليس الأمر مثيرًا للسخرية عندما يؤكد Docker أنه يدعم الأنظمة الأساسية التالية:

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 عندما تكون هذه المشكلة منتشرة بشكل واضح. من الواضح أن Docker يجب أن يسقط الدعم الشامل لنواة معينة في توزيعات معينة.

أنا أستخدم CentOS و kernel ، ويبدو أن ترقية kernel قد حسنت من مشكلة استخدام devicemapper للهروب.

بغض النظر ، شكرا لعملكsnitm.

بالنسبة لأولئك الذين يواجهون هذه المشكلة على Ubuntu ، تأكد من قيامك بتنظيف صور / حاويات عامل الإرساء القديمة بشكل مناسب. اكتشفت أن برنامج التنظيف الخاص بي لم يكن قيد التشغيل عندما اعتقدت أنه كان كذلك ، ولهذا السبب كان يستخدم مساحة كبيرة.

# بن / باش

احذف جميع الحاويات

عامل ميناء rm $ (عامل ميناء ps -a -q)

احذف جميع الصور

docker rmi $ (docker images -q)
""

لاحظ TylerMills أن docker rm لن يزيل وحدات التخزين التي تم إنشاؤها بواسطة الحاويات. إذا كانت الحاويات الخاصة بك تستفيد من وحدات التخزين ، فيجب عليك استخدام docker rm -v لتقوم عامل الشحن بإزالة وحدات التخزين أيضًا.

snitm لقد حصلنا للتو على هذا أيضًا (باستخدام Ubuntu 14.04). على الرغم من أنه قد لا يكون خطأ Docker على وجه التحديد ، إلا أنه يجب أن يكون لديهم مصلحة قوية في إصلاح هذا لأنه ينعكس بشكل سيء على التجربة بأكملها.

لاحظ أيضًا أنني اصطدمت بهذه المشكلة وهذا ما فعلته لإصلاحها:

على الرغم من ذلك ، في حالتي ، نظرًا للجهاز الذي تم تثبيت / var عند الوصول إلى 100٪ من الاستخدام ، فإن الطريقة الوحيدة لمنع المضيف من الدخول في حالة من الذعر في kernel هي إنهاء عملية عامل الإرساء مباشرةً (على سبيل المثال ، قد يؤدي إصدار أي أوامر عامل ميناء إلى الذعر).

ثم اقتل أي عمليات يدويًا باستخدام devicemapper mounts باستخدام هذا الأمر:

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

ثم تمكنت من إلغاء تثبيت أي جهاز تثبيت خرائط باستخدام:

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

أطلقت هذه الخطوات جميع واصفات الملفات التي سمحت لي باستعادة المساحة / حذف الملفات مهما كان ..

في هذه المرحلة من حالتي ، كان من المنطقي نقل دليل / var / lib / docker إلى حامل به مساحة أكبر وتكوين عفريت عامل الإرساء لاستخدام دليل رئيسي مختلف باستخدام الوسيطة -g

بفضل الكسندر لارسون عبر آدم ميلر

متابعة لتعليق https://docs.docker.com/installation/ubuntulinux/

JohnMorales شكرا. سيكون تحذيرًا صغيرًا من Docker حول هذا الأمر فكرة رائعة.

+1

+1

لقد حصلنا مؤخرًا على نظام تشغيل Ubuntu 14.04.2 LTS (3.16.0-30 عام) وما زلنا نكافح لإيجاد حل. يبدو أن التبديل إلى CentOS 6.6 (الذي يفترض أنه يحتوي على إصلاح النواة) أو تركيب وحدة تخزين بها قرص أكبر هي الحلول الوحيدة.

هل وجد أي شخص يقوم بتشغيل Ubuntu حلاً مقبولاً؟

أوافق - يجب على Docker معالجة هذه المشكلة - إنها خلل خطير يحتاج إلى وثائق ورسائل تحذير ، لذلك لا يقع المزيد من الأشخاص في نفس الفخ بسذاجة.

أتفق معnatea
أواجه نفس المشكلة مع redhat 6.5 وهو وضع علامة استفهام كبيرة إذا كان عامل الشحن جاهزًا للإنتاج وبدأنا في البحث عن بدائل.
لا أمانع حتى في الحصول على حل يدوي لحل المشكلة ، لكن في الوقت الحالي ، لست على دراية بأي منها ممكن.

sagiegurarie كن على علم بأننا

لذا فإن إجابة القضية رقم 11643 ليست ذات صلة؟ هذا يعني أنه لا يمكننا استخدام redhat 6.5؟

nateasagiegurari ما يعمل بالنسبة لنا هو دليل "الإصلاح" الذي اقترحهTylerMills

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

الجانب السلبي ، بالطبع ، هو أنه يتعين عليك بعد ذلك إعادة سحب جميع الصور وتشغيل الحاويات مرة أخرى.

bkeroackdsc أتذكر أنني حذفت جميع الحاويات والصور من قبل أيضًا ولم يحل ذلك الأمر ، لكنني

مرحبا! أرغب في معرفة ما إذا كانت هذه المشكلة لا تزال موجودة في ubuntu-15.04. وهو الآن في نواة لينكس 3.19. شكرا جزيلا.

إذا كنت تستخدم Ubuntu-15.05 مع تلك النواة ، فلماذا لا تستخدم التراكب ، فهذا هو الطريق
أفضل من devicemapper

في الخميس ، 7 مايو 2015 الساعة 11:26 صباحًا ، كتب Dreamcat4 [email protected] :

مرحبا! أرغب في معرفة ما إذا كانت هذه المشكلة لا تزال موجودة في ubuntu-15.04.
وهو الآن في نواة لينكس 3.19. شكرا جزيلا.

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99968299.

تضمين التغريدة كيف تبدو؟ هل تستخدم تراكب؟ لقد كنت أفترض (حتى الآن) أن دعم التراكب لا يزال تجريبيًا اعتبارًا من 3.19 kernel.

نعم أستخدم التراكب :) نأمل أن نرفع القائمة في 1.7 خسرنا
استخدمها وأحبها

في يوم الخميس الموافق 7 مايو 2015 ، كتب Dreamcat4 [email protected] :

jfrazelle https://github.com/jfrazelle أوه صحيح. كيف تبدو؟ فعل
هل تستخدم تراكب؟ لقد كنت أفترض (حتى الآن) ذلك
كان دعم التراكب لا يزال تجريبيًا اعتبارًا من 3.19 kernel.

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99982543.

sagiegurari لماذا ستلتزم بـ 6.5؟ هناك عدد من التحديثات والإصلاحات التي تفتقدها من خلال عدم الانتقال إلى 6.6 ، بما في ذلك CVEs الجديرة بالأخبار مع الأسماء.

jperrin لأنه ليس قراري :)
على أي حال ، أحاول التحقق من جميع الفرق لمعرفة ما إذا كان redhat 7 سيكون مناسبًا للإنتاج.

يبدو أن هذا لا يزال يمثل مشكلة في CentOS7 (3.10.0-123.el7.x86_64). لقد قمت بإعداد صندوق CentOS جديد وقمت بتثبيت docker v1.6.0. لا يقل حجم ملف بيانات devicemapper أبدًا بعد sudo docker rmi. إنني أتطلع إلى الحصول على صندوق CentOS6.6 لتجربته على ذلك.

يبدو أن الإصدار 1.6.0 على Ubuntu 14.04 له تأثير إيجابي (أكثر من الإصدار 1.5.0)

يبدو أنه يعمل أيضًا بشكل جيد على centos 7 والذي أعتقد أنه يمكن أيضًا قوله لـ redhat 7
لكن redhat 6.5 ليست كذلك ، وأقترح أن أذكر ذلك في المستندات.

يجب أن يعمل هذا في أحدث عامل إرساء في المنبع. ويبدو أن التعليق الأخير من sagiegurari يشير إلى ذلك. (يعمل على سنتوس 7).

إذا كان الأمر كذلك ، يجب أن نغلق هذا الخطأ.

فهل ما زالت هذه المشكلة تحدث مع عامل الرصيف الأخير؟ إذا لم يكن كذلك ، فلنغلقه.

حسنًا .... يبدو أن إجراء المزيد من الاختبارات يعطي نتائج غير مؤكدة.
دعنا نقول إنه أفضل بكثير ، ولكن ربما لا يزال هناك تسرب ، فقط أبطأ كثيرًا.
سأجري المزيد من الفحوصات للتأكيد.

تضمين التغريدة

هل يمكنك أن تعطيني مزيدًا من التفاصيل حول المشكلة التي تواجهها وبيئتك أيضًا. يشير عنوان المشكلة إلى أن المساحة لا يتم استعادتها عند حذف الصورة / الحاوية ، ويجب ألا يواجه عامل الإرساء الأحدث مثل هذه المشكلات.

هل يمكنك من فضلك أخذ عامل إرساء علوي ، وبناء ثنائي ديناميكي ، وإنشاء تجمع رقيق جديد (في دليل جديد / var / lib / docker /) ، وسحب صورة ، وحذفها وإلقاء نظرة على معلومات عامل الإرساء ومعرفة ما إذا تم تحرير المساحة أو ليس.

سوف أجري المزيد من الاختبارات ونأمل أن الأسبوع المقبل لتقديم المزيد من المعلومات الدقيقة.

أعترف أنني أراه في آلة البناء الخاصة بنا حيث نقوم بإنشاء وإزالة الكثير من الصور (أثناء الإنشاء نفسه) + تشغيل Docker Registry 2.0 (الذي نقوم دائمًا بدفع الصور المختلفة بعلامة "الأحدث") + تشغيل بعض الحاويات قم بإجراء اختبار أولي للتأكد من أن كل شيء يعمل بشكل جيد (لا يُفترض في الواقع تشغيل الاختبار على هذا الجهاز ، لكننا في مرحلة مبكرة لذلك نقوم بإنشاء / إيقاف / rm الكثير من الحاويات).

صورنا كبيرة حقًا ، وأحيانًا أرى حجمًا افتراضيًا يزيد عن 2 جيجا بايت ، لذلك إذا كانت هناك مشكلة ، فإنها تظهر نفسها بشكل أسرع من الصور المعتادة التي عادة ما تكون حوالي 400 مجم.

على أي حال ، سأحاول إجراء بعض الاختبارات لمعرفة السلوك وتقديم مزيد من التفاصيل الأسبوع المقبل.

باستخدام Docker الإصدار 1.6.0 ، الإنشاء 4749651 / 1.6.0 على Linux kernel 3.14.35-28.38.amzn1.x86_64

تؤدي إزالة الصور إلى تقليل مساحة القرص التي يطالب بها عامل الإرساء.

تضمين التغريدة

هل يمكننا إغلاق هذه المشكلة التي لا أعتقد أنها في أحدث عامل إرساء لدينا مشكلة في استعادة مساحة الصورة / الحاوية من ملفات oop. إذا ظهر شيء محدد ، فيمكن للمرء أن يفتح مشكلة جديدة بتفاصيل محددة.

rhvgoyal لا أرى سببًا للاستعجال وإغلاق هذه المشكلة بعد أن اشتكى الكثير من الأشخاص من العديد من الأنظمة الأساسية / الإصدارات.

تضمين التغريدة

لا أعرف ما الذي نكسبه من إبقاء القضية مفتوحة. أعلم أنه تم إصلاحه في المنبع. هناك الكثير من القضايا المفتوحة. يستخدمها الناس كلوحة تحكم لتدوين الملاحظات.

أشعر أن إبقاء المشكلة مفتوحة أمرًا منطقيًا فقط إذا كانت هناك مشكلة حقيقية قابلة للتكرار. بخلاف ذلك ، تستمر قائمة المشكلات هذه في النمو ومن الصعب تحديد أي منها يجب التركيز عليه.

لا أحد يمنعك من إضافة المزيد من البيانات إلى هذه المشكلة بمجرد حصولك على ذلك.

rhvgoyal ما العلامة التي تشير إليها من قبل المنبع الأخير؟

rhvgoyal قل الالتزام الأخير. لقد قمت فقط باستنساخ أحدث شجرة بوابة واختبرتها. هل هو مهم حقا؟

تم الإبلاغ عن العديد من المشكلات في إصدارات عامل الإرساء القديمة والحبوب القديمة. أعتقد أن الخطوة الأولى يجب أن تكون معرفة ما إذا كانت نفس المشكلة مرئية على أحدث عامل إرساء وأحدث نسبيًا kernerl. هذا يعطينا فكرة عما إذا كانت لا تزال مشكلة أو شيء لم يتم إصلاحه في الإصدارات القديمة.

عندما يعود شخص ما ويقرأها في المستقبل ، نعم. كنت أرغب في معرفة الإصدار الذي تم إصلاحه فيه.

نصدر المرتجعات في حالة أجهزة الاسترجاع. لقد تم في الواقع عودة طويلة. أعتقد أنه يجب أن يكون 1.6.

تم اختبار

إذا أشرت إلى تعليقي الأول في هذه المشكلة ، فسترى أنني حاولت أيضًا استخدام الإصدار 1.6.0 على centos7 وما زلت أعاني من المشكلة.

تضمين التغريدة

حسنًا ، هل أنت قادر على إعادة إنتاجه؟ ما نوع البركة الرقيقة التي استخدمتها (فوق الأجهزة الحلقية؟). هل أعدت تشغيل عامل الإرساء أم حدث ذلك في المرة الأولى التي تبدأ فيها عامل الإرساء؟

في بعض الحالات ، قد يحدث أن يستخدم عامل الإرساء أجهزة حلقة ثم يتم إعادة تشغيل عامل الإرساء ، ويمكن أن يحدث أن التجمع لم يتم إغلاقه لأن بعض الأجهزة كانت مشغولة في مكان ما. عند إعادة تشغيل عامل الميناء
يجد التجمع هناك بالفعل وليس لديه علم بأن أجهزة الاسترجاع قيد الاستخدام ولا يصدر تجاهلًا. أتساءل ما إذا كنت قد ركضت إلى هذا الوضع؟

CentOS 7

إصدار Docker 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% /

بعد بعض عامل ميناء 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% /

تضمين التغريدة

حسنًا ، لقد قمت الآن بتشغيل صورة centos7 وحاولت docker 1.6 ولا أرى المشكلة. ها هي الخطوات.

[ root @ centos7-generic ~] # إصدار عامل
إصدار العميل: 1.6.0
إصدار واجهة برمجة تطبيقات العميل: 1.18.1
إصدار Go (العميل): go1.4.2
Git الالتزام (العميل): 8aae715 / 1.6.0
OS / Arch (العميل): linux / amd64
إصدار الخادم: 1.6.0
إصدار Server API: 1.18.1
إصدار Go (الخادم): go1.4.2
Git الالتزام (الخادم): 8aae715 / 1.6.0
OS / Arch (الخادم): linux / amd64

يوجد بالفعل صورة واحدة مستوردة.

[ root @ centos7-generic ~] # صور عامل ميناء
تم إنشاء معرف صورة العلامة بالمستودع بحجم افتراضي
docker.io/fedora آخر ded7cd95e059 منذ أسبوعين 186.5 ميغابايت

هنا هو إخراج معلومات عامل الإرساء.

root @ centos7-generic ~] # معلومات عامل
حاويات: 0
الصور: 2
برنامج تشغيل التخزين: devicemapper
اسم البركة: docker-253: 1-50331788-pool
حجم حوض السباحة: 65.54 kB
دعم نظام الملفات: xfs
ملف البيانات: / dev / loop0
ملف البيانات الوصفية: / dev / loop1
مساحة البيانات المستخدمة: 525.5 ميجا بايت
إجمالي مساحة البيانات: 107.4 جيجا بايت
مساحة البيانات المتوفرة: 20 جيجا بايت
مساحة البيانات الوصفية المستخدمة: 892.9 kB
إجمالي مساحة البيانات الوصفية: 2.147 جيجابايت
مساحة البيانات الوصفية المتوفرة: 2.147 جيجابايت
دعم Udev Sync: صحيح
ملف حلقة البيانات: / var / lib / docker / devicemapper / devicemapper / data
ملف حلقة البيانات الوصفية: / var / lib / docker / devicemapper / devicemapper / metadata
إصدار المكتبة: 1.02.93-RHEL7 (2015-04-28)
سائق التنفيذ: أصلي -0.2
إصدار النواة: 3.10.0-229.el7.x86_64
نظام التشغيل: CentOS Linux 7 (Core)
وحدات المعالجة المركزية: 2

[ root @ centos7-generic ~] # عامل ميناء rmi فيدورا
بدون علامات: فيدورا: الأحدث
محذوف: ded7cd95e059788f2586a51c275a4f151653779d6a7f4dad77c2bd34601d94e4
محذوف: 48ecf305d2cf7046c1f5f8fcbcd4994403173441d4a7f125b1bb0ceead9de731

[ root @ centos7-generic ~] # معلومات عامل
حاويات: 0
الصور: 0
برنامج تشغيل التخزين: devicemapper
اسم البركة: docker-253: 1-50331788-pool
حجم حوض السباحة: 65.54 kB
دعم نظام الملفات: xfs
ملف البيانات: / dev / loop0
ملف البيانات الوصفية: / dev / loop1
مساحة البيانات المستخدمة: 307.2 ميجابايت
إجمالي مساحة البيانات: 107.4 جيجا بايت
مساحة البيانات المتوفرة: 20.22 جيجابايت
مساحة البيانات الوصفية المستخدمة: 733.2 كيلو بايت
إجمالي مساحة البيانات الوصفية: 2.147 جيجابايت
مساحة البيانات الوصفية المتوفرة: 2.147 جيجابايت
دعم Udev Sync: صحيح
ملف حلقة البيانات: / var / lib / docker / devicemapper / devicemapper / data
ملف حلقة البيانات الوصفية: / var / lib / docker / devicemapper / devicemapper / metadata
إصدار المكتبة: 1.02.93-RHEL7 (2015-04-28)
سائق التنفيذ: أصلي -0.2
إصدار النواة: 3.10.0-229.el7.x86_64
نظام التشغيل: CentOS Linux 7 (Core)
وحدات المعالجة المركزية: 2

انخفض استخدام إشعار البيانات من 525 ميجا بايت إلى 307 ميجا بايت. لذا فإن حذف صورة ما أعادني المساحة.

حسنًا ، لقد نسيت أن ألصق حجم ملف الحلقة قبل العملية وبعدها. ها هو.

• قبل سحب الصورة.
  $ cd / var / lib / docker / devicemapper / devicemapper
  بيانات du -h $
  293 مليون بيانات
• بعد سحب الصورة
  [ root @ centos7-generic devicemapper] # بيانات du -h
  499 مليون بيانات
• بعد حذف الصورة
  [ root @ centos7-generic devicemapper] # بيانات du -h
  293 مليون بيانات

لذلك تقلص ملف الحلقات الخاص بي بالفعل بعد حذف الصورة. أعتقد أن هذا ما تشكو منه.

تضمين التغريدة

هل تستخدم ملفات الحلقات؟ لم تكن مرئية في معلومات عامل الإرساء الخاص بك. أعتقد أنك تواجه نفس المشكلة حيث كان هناك بالفعل عندما بدأ عامل ميناء حوض السباحة.

هل يمكنك التحقق من حجم ملفات دعم الحلقة (/ var / lib / docker / devicemapper / devicemapper / data) والتأكد من تقلص الملف بعد حذف الصورة. (du -h).

تضمين التغريدة
CentOS 7 ، إصدار Docker 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

تضمين التغريدة

حسنًا ، حجم جهاز الحلقة ينخفض ​​بالفعل.

كما أنني تحققت من الرمز. سنقوم بإصدار تجاهل حتى إذا وجد عامل الشحن حوضًا رقيقًا موجودًا بالفعل عند إعادة التشغيل.

    // 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 الآن لدينا نقطتا بيانات تم

CentOS 6.6.1

إصدار Docker 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

بعد بعض عامل ميناء 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

حسنًا ، حتى في 1.5 يعمل.

لقد اختبرت هذا على جهاز جديد.

إصدار Docker 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

اسمحوا لي أن أعرف إذا كان لديك أي تفاصيل أخرى عن جهازي أو الإصدارات وما إلى ذلك.

تضمين التغريدة

يبدو أنك تقوم بتثبيت جهاز منفصل على / var. ما هو نظام الملفات على هذا الجهاز وما هي خيارات التحميل؟

كما يمكنك أن تعطيني متابعة.

• جدول dmsetup
• حالة dmsetup
• cat / etc / sysconfig / docker-storage

هل يمكنك تجربة الحالة الأبسط للاحتفاظ بـ / var على الجذر نفسه باستخدام نظام ملفات xfs. محاولة تضييق نطاق المشكلة قليلاً.

تضمين التغريدة

لقد قمت بتثبيت قرص آخر مع قسم ext4 على / var / lib / docker بحيث تكون ملفات دعم الاسترجاع على ext4 (بدلاً من xfs) وما زالت الأشياء تعمل من أجلي.

/ dev / vdb1 on / var / lib / Docker type ext4 (rw ، relatime ، seclabel ، data = أمر)

لست متأكدًا حقًا من الميزات المميزة في الإعداد الخاص بك.

على وجه التحديد ،

• قبل السحب
  / 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

تضمين التغريدة

الاختلاف الرئيسي الآخر بين الإعداد والإعداد الخاص بي هو إصدار kernel. أنا أستخدم "3.10.0-229.el7.x86_64" بينما يبدو أنك تستخدم "3.10.0-123.el7.x86_64". هل يمكنك ترقية النواة الخاصة بك وتجربتها.

شكرا للمساعدة rhvgoyal. لن أتمكن من تحديث النواة اليوم. ولكن إليك الإعدادات التي طلبتها:

/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 = أمر)

• قبل سحب الصورة
  [ root @ centos7-generic-2 devicemapper] # بيانات du -h
  293 مليون بيانات
• بعد سحب الصورة
  [ root @ centos7-generic-2 devicemapper] # بيانات du -h
  501M بيانات
• بعد إزالة الصورة
  [ root @ centos7-generic-2 devicemapper] # بيانات du -h
  501M بيانات

لذلك لسبب ما إذا كان ملف الاسترجاع على نظام ملفات ext3 ، فإنه لا يعمل. قد يكون ext3 قديمًا بما يكفي بحيث لا تعمل عمليات تجاهل الحلقة عليه.

شكرًا ، بمجرد أن رأيت نظام الملفات هو ext3 ، اعتقدت أنه يمكن أن يكون كذلك. أعتقد أنه إذا كنت قادرًا على إعادة إظهار المشكلة على ext3 ، فيمكننا استدعاء هذه المشكلة مغلقة. سيكون مرجعا جيدا للآخرين.

للإشارة ، كانت أمثلة عملي هي Docker 1.6.2 على نظام ملفات xfs و Docker 1.6.0 و 1.5.0 على ext4.

تضمين التغريدة

هل يمكننا إغلاق هذا. تعمل استعادة المساحة بشكل جيد على xfs و ext4. يبدو أن ext3 أكبر من أن تدعمه.

vbattsrhvgoyal IIRC، وهناك توافق الاختيار الذي يتحقق الأساسي نظام الملفات. ربما يجب علينا إضافة شيك ext3 إذا كانت هذه هي المشكلة هنا؟

تعديل:
كمرجع؛ daemon / graphdriver / overlay / overlay.go # L115

يستخدم برنامج Loop driver Fallocate () لإحداث ثقب في الملف عندما يأتي الإهمال. تتحقق صفحة رجل Linux من Fallocate () من أنها غير مدعومة على ext3.

/ *
ليست كل أنظمة الملفات تدعم FALLOC_FL_PUNCH_HOLE ؛ إذا كان نظام الملفات لا يدعم العملية ، يتم إرجاع خطأ. العملية مدعومة على الأقل في أنظمة الملفات التالية:
* XFS (منذ Linux 2.6.38)
* ext4 (منذ Linux 3.0)
* Btrfs (منذ Linux 3.7)
* tmpfs (منذ Linux 3.5)
* /

تضمين التغريدة

إذا أراد شخص ما تشغيل Docker على ext3 ، أعتقد أننا يجب أن نسمح بذلك. فقط لن يحصلوا على دعم تجاهل وبالتالي لن يتقلص حجم ملف الحلقة عند حذف الصورة / الحاويات.

rhvgoyal ماذا عن إظهار هذا بـ docker info ؟ على غرار الناتج Udev Sync Supported .

تضمين التغريدة

لدينا بالفعل إدخال في Docker info "Backing filesystem". لست متأكدًا من السبب الذي يجعله يقول extfs بدلاً من الدقة حول ext2 / ext3 / ext4.

قد يكون تحذيرًا في وقت بدء التشغيل في السجلات يجب أن تفعله هنا. شيء مشابه للتحذير من استخدام الأجهزة الحلقية لبركة رقيقة.

تضمين التغريدة

وأعتقد أننا يجب أن نفعل ذلك فقط إذا تأثر الكثير من الناس بهذا. إذا لم يكن الأمر كذلك ، فإننا نقوم فقط بإنشاء المزيد من العمل والرمز وقد لا يكون الأمر يستحق ذلك.

ال syscall.Statfs_t Struct ، مع الحقل Type على ext2 و ext3 و ext4 ، كلها تُرجع 0xef53 ، وهذا ما نستخدمه لاكتشاف سحر نظام الملفات.

بنية syscall.Statfs_t Struct ، مع حقل النوع في ext2 و ext3 و ext4 ، كلها تُرجع 0xef53 ، وهذا ما نستخدمه لاكتشاف سحر نظام الملفات.

المشكله. كان من الجيد الحصول على هذه المعلومات لتسهيل تحديد المشكلات المبلغ عنها.

أعتقد ، يجب علينا إغلاق هذا بعد ذلك؟

إغلاق لأن هذه مشكلة تتعلق بأن ext3 قديم. الرجاء استخدام ext4 أو xfs

هل تعتقد أنه يمكن توثيق ذلك بشكل أفضل في وثائق Docker الرئيسية بطريقة أو بأخرى؟

سواء كانت المشكلة تتعلق بنظام الملفات أم لا ، انظر إلى مقدار الارتباك الذي أحدثه هذا في مشكلتين حديثتين.

شكر.

العودة إلى الإصدار رقم 9786

dbabits نعم ، أعتقد أن ذكر أن ext3 به بعض المشكلات قد يكون جديرًا بالذكر في المستندات. لا توجد فكرة بعد ما هو الموقع المناسب.

لديك نفس / مشكلة مماثلة مع XFS.
كان على kernel "3.10.0-123.el7.x86_64" ، ولكن تم التحديث الآن على "3.10.0-229.el7.x86_64".

يتم حذف Eveything (حاوية ، صور) ولكن لا تزال البيانات تحتوي على 100 جيجابايت.
أي أفكار ، مساعدة؟

[ root @ docker0101 ~] # ls -alh / data / docker / devicemapper / devicemapper /
إجمالي 80 جرام
drwx ------ 2 جذر 32 يونيو 8 16:48.
drwx ------ 5 جذر 50 يونيو 9 07:16 ..
-rw ------- 1 جذر 100G يوليو 16 بيانات 21:33
-rw ------- 1 root root 2.0G 17 يوليو 09:20 بيانات وصفية

[ root @ docker0101 ~] # uname -a
Linux docker0101 3.10.0-229.7.2.el7.x86_64 # 1 SMP الثلاثاء 23 يونيو 22:06:11 بالتوقيت العالمي المنسق 2015 x86_64 x86_64 x86_64 GNU / Linux

[ root @ docker0101 ~] # cat / etc / redhat-release
إصدار CentOS Linux 7.1.1503 (Core)

[ root @ docker0101 ~] # عامل تشغيل ps -a
أسماء منافذ الحالة التي تم إنشاؤها بأمر صورة معرف الحاويات

[ root @ docker0101 ~] # صور عامل ميناء -a
تم إنشاء معرف صورة العلامة بالمستودع بحجم افتراضي

[ root @ docker0101 ~] # معلومات عامل
حاويات: 0
الصور: 0
برنامج تشغيل التخزين: devicemapper
اسم البركة: docker-253: 0-268599424-pool
حجم حوض السباحة: 65.54 kB
دعم نظام الملفات: xfs
ملف البيانات: / dev / loop0
ملف البيانات الوصفية: / dev / loop1
مساحة البيانات المستخدمة: 85.61 جيجابايت
إجمالي مساحة البيانات: 107.4 جيجا بايت
مساحة البيانات المتوفرة: 40.91 ميجابايت
مساحة البيانات الوصفية المستخدمة: 211.4 ميجابايت
إجمالي مساحة البيانات الوصفية: 2.147 جيجابايت
مساحة البيانات الوصفية المتوفرة: 40.91 ميجا بايت
دعم Udev Sync: صحيح
ملف حلقة البيانات: / data / docker / devicemapper / devicemapper / data
ملف حلقة البيانات الوصفية: / data / docker / devicemapper / devicemapper / metadata
إصدار المكتبة: 1.02.93-RHEL7 (2015-04-28)
سائق التنفيذ: أصلي -0.2
إصدار النواة: 3.10.0-229.7.2.el7.x86_64
نظام التشغيل: CentOS Linux 7 (Core)
وحدات المعالجة المركزية: 4
إجمالي الذاكرة: 11.58 جيجا بايت
الاسم: docker0101

[ root @ docker0101 ~] # جدول dmsetup
vg1-lvol0: 0 167772160 خطي 8:16 2048
docker-253: 0-268599424-pool: 0 209715200 Thin-pool 7: 1 7: 0128 32768 1 skip_block_zeroing

[ root @ docker0101 ~] # حالة dmsetup
vg1-lvol0: 0 167772160 خطي
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 عامل إرساء
الاسم: عامل ميناء
الإصدار: 1.6.2
الإصدار: 14.el7.centos
العمارة: x86_64
تاريخ التثبيت: الجمعة 17 يوليو 2015 09:19:54 ص CEST
المجموعة: غير محدد
الحجم: 33825026
الترخيص: ASL 2.0
التوقيع: RSA / SHA256 ، الأربعاء 24 يونيو 2015 05:43:12 ص CEST ، معرف المفتاح 24c6a8a7f4a80eb5
المصدر RPM: docker-1.6.2-14.el7.centos.src.rpm
تاريخ البناء: الأربعاء 24 يونيو 2015 03:52:32 ص CEST
بناء المضيف: worker1.bsys.centos.org

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

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

tomlux يُقصد بوضع استرجاع devicemapper الذي تستخدمه في الغالب كوسيلة للتلاعب بسهولة باستخدام عامل الإرساء. للعمل الجاد ، سيكون الاسترجاع أبطأ ، وسيكون له بعض القيود. أوصي بشدة بقراءة http://www.projectatomic.io/docs/docker-storage-recommendation/

ستحصل على أداء أفضل ، ولن تصل إلى مثل هذه الأشياء ، بافتراض أنك قمت بتطبيق جميع تحديثات النظام.

تضمين التغريدة

هل يمكنك إضافة "-s" إلى ls. سيعطيك ذلك كتلًا فعلية مخصصة للبيانات وملفات البيانات الوصفية. الآن يظهر الحجم الظاهر للملفات.

إخراج معلومات عامل الميناء مثير للاهتمام بالرغم من ذلك. يبدو أنه يظهر استخدامًا عاليًا.

تضمين التغريدة

لذا يبدو الحجم الفعلي للبيانات وملفات البيانات الوصفية صغيرًا. يمكنك استخدام "ls -alsh" حتى تكون الأحجام أكثر قابلية للقراءة.

لذلك يبدو أن حجم ملف البيانات يبلغ حوالي 79 ميجا بايت وحجم ملف البيانات الوصفية حوالي 202 كيلو بايت.

أعتقد أن إحصائيات البلياردو الرفيعة إلى حد ما حول عدد الكتل المستخدمة لا تبدو صحيحة. هل إعادة تشغيل الجهاز يحل المشكلة؟

لقد أجريت إعادة تشغيل بعد تحديث kernel دون نجاح.

حسنًا ، ملفات الحلقات كبيرة ويعتقد التجمع أنه يحتوي على الكثير من الكتل المستخدمة. لذلك هناك شيء ما يستخدم تلك الكتل. هل يمكن أن تعطيني إخراج.

• عامل تشغيل ps -a
• صور عامل ميناء
• ls / var / lib / dokcer / devicemapper / metadata / | مرحاض -l
• اغلاق عامل ميناء وتشغيل التالية.
  thin_dump / var / lib / docker / devicemapper / devicemapper / metadata | grep "جهاز dev_id" | مرحاض -l

سيوضح هذا عدد الأجهزة الرقيقة الموجودة في المسبح.

حسنًا ،
الآن لدينا حاويات ميتة ولكن لا توجد صور.
فعلت بالفعل إعادة التشغيل.

يبدو أن هناك خطأ ما في الجهاز.
لا أريد إرسال بريد عشوائي لهذه المشكلة.
يمكنني أيضًا "rm -f / var / lib / docker" وإعادة بناء حاوياتي. كل شيء مكتوب.

فعل "حالة dmsetup"

يبدو أن حمام السباحة في حالة سيئة وعلى الأرجح بحاجة إلى الإصلاح.

مرحبا،

يبدو أن لدي نفس المشكلة تحت Ubuntu 14.04. ومع ذلك ، فإن سبب وجود مجلدات غير مرغوب فيها (راجع مدونة 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

أصدرت الكثير من مساحة القرص.

لم يتم إصلاح هذا بأي طريقة ذات معنى. في تثبيت Ubuntu 14.04.x ​​المحدّث بالكامل (أحدث إصدار LTS) ومع أحدث إصدار من Docker (تم تثبيته عبر $ wget -qO- https://get.docker.com/ | sh ) ، سيقوم Docker بتسريب المساحة باستمرار دون أي طريقة سهلة لاستعادتها. لا يصدر 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 للتنظيف ، وخيار تقرير حالة جيد وكذلك نوع من المراقبة لمساحة القرص حيث تحدث هذه المشكلة للعديد من الأشخاص على العديد من الأنظمة الأساسية.

تضمين التغريدة

السبب الذي أطالب به هو أن المجلدات المعزولة لا تتعلق بهذه المشكلة ،
لا علاقة لها devicemapper.

لا تعد المجلدات المعزولة
للحاوية يتم حذفها تلقائيًا عند حذف الحاوية.
هذه _not_ الحالة (وحسب التصميم) ، لأن وحدات التخزين يمكن أن تحتوي على بيانات
يجب أن يستمر ذلك بعد حذف الحاوية.

_لحذف وحدة تخزين مع حاوية_ ، استخدم docker rm -v [mycontainer] .
ستتم إضافة وظائف إدارة الحجم (راجع https://github.com/docker/docker/pull/14242 و https://github.com/docker/docker/issues/8363) ،
وسيسمح لك بإدارة وحدات التخزين "المعزولة".

لا يجب أن يكون الحجم المتزايد /var/lib/docker مؤشرًا
يقوم هذا الجهاز بتسريب البيانات ، بسبب زيادة حجم هذا الدليل
يمكن أن يكون أيضًا نتيجة للكميات (اليتيمة) التي لم يتم تنظيفها
من قبل المستخدم (يقوم عامل الإرساء بتخزين جميع بياناته في هذا المسار).

آمل حقًا أن يوفر هذان العنصران الإمكانيات المطلوبة.
لقد فهمت العنصر الثاني ، لكن الأول (# 14242) ، لا يشرح في الجزء العلوي ما يدور حوله بصرف النظر عن أنه وحدة تخزين API (بمعنى ، لست متأكدًا من الإمكانات التي يوفرها).

sagiegurari إنه جزء من متطلبات تنفيذ إدارة حجم الصور (هناك بعض مشكلات العلاقات العامة المفتوحة الأخرى). تتمثل الأهداف النهائية في جعل وحدات التخزين مواطنًا من الدرجة الأولى في Docker ، والتي يمكن إنشاؤها / حذفها / إدارتها بشكل منفصل عن الحاويات التي تستخدمها.

swachter شكرًا لنشر هذا الحل البديل ، لقد

لقد أصلحنا مشكلة حجم التسرب باختراق قذر ، نظرًا لأنه كان يمنع بدء تشغيل برنامج عامل الإرساء قبل انتهاء مهلة الخدمة على مضيفي عامل الإرساء لدينا:

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

الذي يعمل على إصلاح المشكلة دون مسح الصور المخزنة مؤقتًا مسبقًا.

هل يمكننا مناقشة مسألة الأحجام المتسربة في إصدار منفصل. مناقشتها هنا تعطي انطباعًا بأنها مشكلة في مخطط جهاز بينما ليست كذلك.

تضمين التغريدة

هل توصلت يومًا إلى استنتاج بشأن ما يحدث في علبة CentOS 7؟ مضيف عامل الإرساء الخاص بي متطابق تقريبًا ، وكنت أعاني من نفس المشكلة. لقد تابعت حتى النقطة التي طلب فيها rhvgoyal تشغيل الأمر thin_dump . بعد ذلك ، ذهبت لبدء برنامج Docker daemon ولم يبدأ. لقد قمت للتو بحذف / 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

تضمين التغريدة

لقد وجدت مصدر مشكلتي. على الرغم من كيفية ظهوره ، إلا أنه لا علاقة له بالقضايا الموجودة في الموضوع. لقد نشأ فقط من سوء فهم لكيفية عمل عامل الميناء. جميع الحاويات الميتة كانت لا تزال تحتفظ بمساحة القرص التي خصصتها أثناء إعدامها. كان علي فقط إزالة جميع جثث الحاوية لتحرير مساحة القرص. أتذكر أن هذا يحدث في هذا الموضوع ، لكنني اعتقدت أنه يُنظر إليه فقط على وحدات التخزين المركبة ، وليس مساحة القرص المخصصة بواسطة الحاوية.

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

tomlux قد تكون هذه هي مشكلتك أيضًا لأن docker ps -a أظهر عدة حاويات Dead .

لا يقوم docker rm بتحرير مساحة قرص الحاوية

boot2docker الأخير في OS X VirtualBox. OS X مصححة بالكامل.

أنا أقوم ببناء حاوية دهون (47 جيجابايت) ولديها مشكلة تشير إلى أنه يجب علي إعادة بناء الحاوية. لذلك أوقفت الحاوية وفعلت عامل الإرساء. فحص مزدوج باستخدام docker ssh"df -h" ، أجد أن استخدام القرص لا يزال 47 جيجابايت. الحاوية 75 جيجا بايت.

لذلك سأحتاج إلى قتل عامل الإرساء VM مرة أخرى.

هل يمكننا إنجاز هذا؟

@ awolfe-silversky هو مساحة القرص _inside_ عاد VM؟ إذا كان خارج VM ، فقد يكون هذا غير ذي صلة.

@ awolfe-silversky أيضا ؛ هل أزلت _image_ أيضًا؟ قد لا تساعد إزالة الحاوية فقط كثيرًا إذا كانت الصورة لا تزال موجودة

@ awolfe-silversky ، هذه المشكلة تدور حول devicemapper - وإذا كنت تستخدم docker-machine / boot2docker ، فمن المرجح أن تقوم بتشغيل aufs . أتساءل أيضًا إذا كان لديك docker rmi 'صورتك الكبيرة.

قيمته تشغيل docker images ، و docker info لمعرفة ما إذا كانت الأمور حقاً رهيبة كما تجعلها تبدو سليمة :)

(نعم ، إذا كان لا يزال لديك vm ، وتمت إزالة الصورة ، فعلينا فتح مشكلة جديدة وتصحيح الأخطاء بشكل أكبر ، حيث وجدت حالة زاوية غريبة)

أنا لم أزل الصورة. إنه من سجل عامل ميناء داخلي.
لقد استخدمت برنامجًا نصيًا awk لحجم الصور - إجمالي 6.9 غيغابايت.

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

إنه متسخ ولكني أعلم أن جميع أحجام الصور بالميغابايت.

إليك كيف كنت أحاول تشخيص الاستخدام:

 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 جيجا.
إصدار Docker 1.10.2 ، بناء 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)

أيضًا ، لماذا يستخدم التثبيت الافتراضي خيار التخزين "غير المستحسن بشدة"؟
لماذا لم يتم إخباري بذلك عند التثبيت؟

لدي نفس المشكلة بالضبط هنا في مثيل 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% /

نظرًا لأن هذا الخطأ موجود منذ سنوات ويبدو أنه لم يتم إغلاقه بعد ، هل يمكنك وضع وثائق عامل الإرساء حول devidemapper حول كيفية تدمير سلامة جميع معلومات عامل الإرساء؟
أعني ، في هذه الصفحة: https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
ضع شيئًا مثل "مخطط جهاز التنظيف" وكيفية القيام بذلك.

سأحاول أن أفعل rm -rf / var / lib / docker لكنني لا أشعر بالراحة عند القيام بذلك. هل يمكن لأحد أن يخبرني ما إذا كان آمنًا؟

أنا أستخدم gentoo linux في جهاز الكمبيوتر المحمول اليومي الخاص بي وحاولت docker للتعلم ولكني تملأ القرص الخاص بي وإعادة تثبيت النظام بالكامل ليس خيارًا لأنه ليس VM وإعادة تثبيت gentoo تستغرق وقتًا.

شكرا لك على عملك.

mercuriete على جهاز

@ ir-fuel: لقد فعلت ذلك للتو والآن لدي هذا:

$ 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-fuel شكرا ، يعمل بشكل جيد. : +1:

إعادة تثبيت docker لتحرير مساحة القرص هي الإجابة الأكثر سخافة التي صادفتها أثناء البحث عن حل لهذه المشكلة. هذا ليس مضيعة للوقت فحسب ، بل إنه غير مسموح به في معظم البيئات. إنها طريقة جيدة لكسب المال إذا كنت تعمل بالساعة.

أنا أتفق تماما. إنه لأمر مدهش أن منتجًا مثل Docker يستمر في التخلص من مساحة القرص دون أي شيء يمكنك فعله حيال ذلك باستثناء إلغاء التثبيت / إعادة التثبيت.

تسجيل الوصول إلى هذه المشكلة مرة أخرى لمعرفة لم يتغير شيء. +1

تم وضع علامة على هذه القضية مغلقة. نحن بحاجة إلى حل. لا يوجد حل بديل ، لا إعادة التكوين. ما هي الحالة الحقيقية وما هي إعدادات التكوين المتضمنة؟ إسقاط وإعادة إنشاء عقدة Docker للإنتاج أمر غير مقبول.

وما هو البديل؟ كيف نتجنب هذا؟

إذا لم تكن هذه الميزة موصى بها للاستخدام - فلماذا هي صامتة وافتراضية
واحد؟ إذا كنت لا تهتم بالأشخاص الذين يستخدمون devicemapper - فقد أكون على ما يرام
مع هذا. لكن قم بإبلاغ المستخدم عنها! هل تدرك مقدار
الأشخاص الذين يعانون من الصداع بسبب هذا "الحل البديل" المذهل الذي استقرت عليه ؟؟
في 23 يونيو 2016 الساعة 4:32 مساءً ، كتب "kpande" [email protected] :

الحل البديل هو تجنب استخدام برنامج تشغيل عامل ربط الجهاز ،
لسوء الحظ.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

هناك دائما rkt ...

لا شك أن النخر العام غير المفيد هو سبب عدم اهتمام أي شخص من المنبع بإعطائك إجابات مناسبة.

لم يجبرك أحد على استخدام Docker.

هذا يشبه إخبار Oracle مطور Java باستخدام PHP بسبب خطأ في JVM. هذا أيضًا لا يتوافق مع درجة المصعد هنا

قبل ثلاث سنوات ، ابتكر Docker تقنية نواة لينكس مقصورة على فئة معينة تسمى الحاوية بسيطة ومتاحة للجميع.

أنا متأكد من أن الكثير من الناس ممتنون لأن Docker أقلعت كما فعلت ولم يكن من الممكن أن يحدث ذلك بدون التطوع من المجتمع. ومع ذلك ، لا ينبغي أن يكون هذا صعبًا للاعتراف بأنه يعاني من مشاكله أيضًا دون التخلي ضمنيًا عن عبارة "أنا مساهم في التيار الرئيسي لذا اصمت واستمع" كلما طرح شخص ما نقطة غير مرغوب فيها.

انتظر. لقد أبلغت عن مشكلة ، وقدمت تفاصيل جهازي والإعداد ،
وهو ما لست مضطرًا لذلك. لم يستجب أي من devteam لخطأي وخطأ الآخرين
تقارير في فترة نصف عام. الآن ذكرت هذه الحقيقة ، أنت تسمي سلوكي
مشاكس؟ هل أنت حتى مفتوح المصدر؟ أنا أبحث عن مشروع Go للعمل عليه و
لن يكون Docker ، أنا أعطيك ذلك. هل هذا هدفك
في 23 حزيران (يونيو) 2016 الساعة 16:45 ، كتب [email protected] "gregory grey":

إذا لم تكن هذه الميزة موصى بها للاستخدام - فلماذا هي صامتة وافتراضية
واحد؟ إذا كنت لا تهتم بالأشخاص الذين يستخدمون devicemapper - فقد أكون على ما يرام
مع هذا. لكن قم بإبلاغ المستخدم عنها! هل تدرك مقدار
الأشخاص الذين يعانون من الصداع بسبب هذا "الحل البديل" المذهل الذي استقرت عليه ؟؟
في 23 يونيو 2016 الساعة 4:32 مساءً ، كتب "kpande" [email protected] :

الحل البديل هو تجنب استخدام برنامج تشغيل عامل ربط الجهاز ،
لسوء الحظ.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

بادئ ذي بدء ، إذا كنت لا تزال تواجه هذه المشكلة ، فيرجى فتح إصدار جديد ؛

انتظر. لقد أبلغت عن مشكلة

لقد أجبت على قضية مغلقة عمرها 3 سنوات ؛ بعد المناقشة أعلاه ، تم حل المشكلة الأصلية. قد تكون مشكلتك هي نفسها ، لكنها تحتاج إلى مزيد من البحث للتأكد ؛ تشير الأخطاء التي تعيدها إلى أنه قد يكون شيئًا آخر.

أوصي حقًا بفتح إصدار جديد ، وعدم التعليق على قضية مغلقة

قدمت تفاصيل جهازي والإعداد ، وهو ما لست ملزمًا به.

لست ملزمًا بذلك ، ولكن بدون تقديم أي معلومات ، فمن غير المحتمل أن يتم حلها. لذلك ، عند الإبلاغ عن خطأ ، يرجى تضمين المعلومات المطلوبة في النموذج:
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

لم يستجب أي من devteam لتقارير الأخطاء الخاصة بي والآخرين في فترة نصف عام.

إذا كنت تقصد "أحد المشرفين" ، فالرجاء أن تضع في اعتبارك أن هناك ما يقرب من 24000 مشكلة و PRs ، وأقل من 20 مشرفًا ، كثير منهم يفعلون ذلك إلى جانب وظيفتهم اليومية. لن يتم ملاحظة كل تعليق خاصة إذا كان يتعلق بموضوع مغلق.

إذا لم تكن هذه الميزة موصى بها للاستخدام - فلماذا هي ميزة صامتة وافتراضية؟

إنه الإعداد الافتراضي إذا لم يتم دعم _aufs_ و _btrfs_ و _zfs_ ، فيمكنك العثور على الأولوية المستخدمة عند تحديد برامج التشغيل ؛ انظر daemon / graphdriver / driver_linux.go . لا يزال فوق التراكب ، لأنه للأسف هناك بعض المشكلات المتبقية في برنامج التشغيل هذا والتي قد يتأثر بها بعض الأشخاص.

اختيار مشغل الرسوم تلقائيًا هو فقط "تشغيل الأشياء" ؛ يعتمد أفضل محرك لحالتك على حالة الاستخدام. لا يمكن لـ Docker اتخاذ هذا القرار تلقائيًا ، لذا فإن الأمر متروك للمستخدم للتهيئة.

إذا كنت لا تهتم بالأشخاص الذين يستخدمون devicemapper - فقد أكون موافقًا على ذلك.

عند قراءة المناقشة أعلاه مرة أخرى ، أرى أن المشرفين على صيانة الأجهزة الأولية قد نظروا في هذه _أوقات متعددة _ في محاولة لمساعدة المستخدمين في الإبلاغ عن هذه المشكلات وحل المشكلة. تم حل المشكلة لمن قاموا بالإبلاغ عنها ، أو في بعض الحالات ، اعتمدت على توزيعات لتحديث إصدارات devicemapper. لا أعتقد أنه يمكن اعتبار ذلك "غير مهتم".

أيضًا ، لماذا يستخدم التثبيت الافتراضي خيار التخزين "غير المستحسن بشدة"؟

يعد التشغيل على الأجهزة الحلقية أمرًا جيدًا لتشغيل عامل الإرساء ، وهو حاليًا الطريقة الوحيدة لإعداد devicemapper تلقائيًا. للإنتاج وللحصول على أداء أفضل بشكل عام ، استخدم Direct-lvm ، كما هو موضح في قسم devicemapper في دليل مستخدم برنامج تشغيل التخزين.

لماذا لم يتم إخباري بذلك عند التثبيت؟

هذا خارج نطاق التثبيت ، حقًا. إذا كنت ستستخدم بعض البرامج في الإنتاج ، فيجب أن يكون من المعقول افتراض أنك تعرف نفسك على هذا البرنامج ، ومعرفة ما هو مطلوب لإعداده لحالة الاستخدام الخاصة بك. حتى أن بعض المشرفين جادلوا فيما إذا كان يجب إخراج التحذير على الإطلاق. Linux ليس نظام تشغيل "ممسك باليد" (هل تعرض التوزيعة الخاصة بك تحذيرًا من إمكانية فقد البيانات إذا كنت تستخدم RAID-0؟ إذا كان لديك منافذ مفتوحة في جدار الحماية الخاص بك؟)

أنا متردد بشدة في إعادة إحياء هذا الخيط القديم مرة أخرى ، ولا توجد حتى الآن نصيحة مفيدة حول كيفية التغلب على هذه المشكلة على جهاز موجود يواجه هذه المشكلة.

هذا هو أفضل جهد لي في tldr ؛ لكامل الموضوع آمل أن يساعد الآخرين الذين يجدون هذا الموضوع.

تمت مواجهة المشكلة

يحتوي حجمك على قدر كبير (ومتزايد) من المساحة وهو /var/lib/docker وأنت تستخدم ext3.

الدقة

ليس لديك اي حظ. قم بترقية نظام الملفات الخاص بك أو شاهد blowing docker away في الأسفل.

تمت مواجهة المشكلة

حجمك يحتوي على قدر كبير (ومتزايد) من المساحة في /var/lib/docker وأنت _لا_ تستخدم ext3 (على سبيل المثال ، النظام الذي يستخدم حاليًا xfs أو ext4)

الدقة

قد تتمكن من استعادة مساحة على جهازك باستخدام أوامر Docker القياسية.

اقرأ 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 / عامل إرساء

يمكنك أيضًا استخدام nuke-graph-directory.sh .

بعد إزالة الملفات كما هو مذكور أعلاه ، لا يمكنني بدء تشغيل Docker بعد الآن:
مارس 02 04:53:40 pmdc001b dockerd [29522]: خطأ في بدء البرنامج الخفي: خطأ في تهيئة مشغل الرسم البياني: open / var / lib / docker / devicemapper / devicemapper / data: لا يوجد مثل هذا الملف أو الدليل

واجهت للتو هذه المشكلة على CentOS 7.3 ولم ترغب في تصحيح مشكلات devmapper الموجودة لأكثر من 3 سنوات ، لذلك اتبعت دليل DC / OS هذا ، وقمت بإزالة الحزم الأصلية ، وتحولت إلى التراكبات ويبدو أن كل شيء يعمل بشكل جيد الآن : https://dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/ (كان لا بد من تعديل أمر ExecStart لإصدار عامل الإرساء 17.03 -> "dockerd --storage-driver = تراكب ")

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

(لم تساعد إزالة الأحجام والصور والحاويات. أدى حذف العناصر في / var / lib / docker إلى حدوث المشكلة الموضحة بواسطة @ gdring2 )

أدى تشغيل docker system prune إلى توفير مساحة كبيرة على أجهزتي.

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

حسنًا ، هذا نوع من ... أعرج.

في حالتي ، وجدت هذه المشكلة بعد أن ألغيت تثبيت Docker وحذفت الدليل /var/lib/docker ، لذلك لم أتمكن من تشغيل ما يعادل service docker stop ... service docker start .

لقد وجدت أن نظامي لم يكن يبلغ عن المساحة من حذف /var/lib/docker كما تم تحريره (كان لدي حوالي 14 جيجا بايت جالس في ما بدا وكأنه طي النسيان)

الإصلاح لهذا هو ببساطة إعادة تحميل نظام الملفات الخاص بك ، في حالتي ، قمت للتو بإعادة التشغيل وتمت استعادة المساحة.

لا أصدق أنها لا تزال مشكلة! هيا يا رفاق ، ما زلت أمتلك ذلك

@ shahaf600 ما هو إصدار عامل https://github.com/moby/moby/issues/3182#issuecomment -228298975

بدون تفاصيل ليس هناك الكثير لتقوله عن وضعك ؛ قد تكون مشكلتك ناتجة عن مشكلة مختلفة ، ولكنها تؤدي إلى نتيجة مماثلة.

حسن

بعد شراء إحدى قطع القمامة هذه ورؤية حالة الدعم ، أعدتها.

هناك مشكلتك الأولىmisterbigstuff ... هل اشتريت شيئًا مفتوح المصدر؟

وأعادها