+1, мне очень интересно услышать обсуждение на эту тему. Моя стратегия до сих пор была

• будьте осторожны, что вы строите / тянете
• будьте готовы сдуть ваш / var / lib / docker: нейтральный_фейс:

@AaronFriel , какая у вас версия Docker? 0.7.1?

/ 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

Затем после того, как docker pull 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 _не_ увеличивает размер файла, но освобождает место в пуле 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

Итак, похоже, что мы не можем повторно спарсифицировать файл loopback, когда устройство thinp отбрасывает блок.

Однако, если я создаю файл внутри fs-образа контейнера, он _does_ освобождает пространство в файле loopback.
Т.е. я сделал это в образе 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

Это увеличило файл данных с 299M до 344M. Но когда я удалил a_file.bin (и немного подождал), он вернулся к 299M.

Итак, мне кажется, что это ошибка devicemapper. Т.е. он перенаправляет сбросы с тонкого устройства на нижележащее устройство, но не сбрасывает при удалении тонких устройств из пула.

Кажется, это проблема ядра, я пытался обойти ее, используя BLKDISCARD, но мне это не удалось. См. Некоторые подробности в этой ошибке: https://bugzilla.redhat.com/show_bug.cgi?id=1043527

Я поместил свой обходной путь в https://github.com/alexlarsson/docker/tree/blkdiscard , но мы все еще изучаем, можем ли мы сделать что-то лучше этого.

Upstream 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. Старый, но проблема не только в Ubuntu.

Та же проблема с 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-system. Моя тестовая виртуальная машина (хост-докер) имеет диск емкостью 8 ГБ, и после многократного создания изображений без их удаления мой диск заполняется. Но после удаления всех образов и контейнеров диск по-прежнему заполнен на 100%. Я решил, что это ошибка ID-10T, но просто сдался и полностью уничтожил виртуальную машину.

Все еще существует в версии 0.7.5 на ubuntu 13.04.

Эта проблема была исправлена ​​PR # 3256, который был недавно объединен. Это исправление будет включено в будущий выпуск.

Я закрываю эту проблему сейчас, потому что исправление было объединено в master.

Примечание: это не _ полностью_ исправлено, пока вы также не запустите ядро ​​с 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, это может быть для меня простым переключением.

@logicminds Я даже не знаю, есть ли этот коммит в

Я собираюсь создать такой инструмент, как fstrim, который можно использовать, чтобы вернуть пространство.

Проблема @alexlarsson https://bugzilla.redhat.com/show_bug.cgi?id=1043527 была закрыта, официально из-за «недостаточности данных». Означает ли это, что патч не попадет в ядро? Это еще нужно?

@vrvolle Патч, который делает обходной путь, который использует docker, уже находится в

У меня все еще есть эта проблема с docker 0.9 на centos 6.5 с ядром по умолчанию 2.6.32.

Я не уверен, что понимаю, что вы сказали ранее об этой фиксации в устройстве-картографе. Не могли бы вы подтвердить, что если я перенесу ядро ​​на 3.8, эта ошибка должна быть решена?

Заранее спасибо.

@ nicolas-van Нет, вам нужен этот коммит: https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316

Он находится в версии 3.14 и может быть в различных бэкпортах 3.xy

Некоторое время назад я установил докер для создания образа и запуска его в контейнере. Затем через некоторое время я очистил все изображения и контейнеры, включая приложение-докер и основную папку.
Теперь я понимаю, что из 4 ГБ / 24 ГБ свободных / использованных (df -h) команда du / -sh сообщает только 10 ГБ, поэтому еще 10 ГБ не учитываются. Это, скорее, меньше размера временных изображений, созданных с помощью Docker, может ли это быть связано с этой ошибкой. Я использовал centos 6.5 и docker 0.9.

Я удалил docker с помощью yum и разработчиков из / dev / mapper / docker * с помощью dmsetup, а также rm / var / lib / docker -Rf, и все же отчеты о дисках с использованием df 10gb, которые я нигде не могу найти.

@Jacq Возможно, какой-то файл все еще поддерживается процессом, для которого открыт файловый дескриптор. Вы перезагружались? Это гарантирует, что этого не произойдет.

Я запускаю Linux 3.14.4-1-ARCH и docker 0.11.1, удалил все образы и контейнеры.
и файл / var / lib / docker / devicemapper / devicemapper просто застрял, потребляя около 1,5 ГБ

вот вывод после того, как я возился с некоторыми вещами mongodb, я думаю, размер файла должен быть распределен редко, потому что мой / 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, так что удачи в этом.

Ой ... Куда делись те 25 ГБ? О, в этот файл .... Я использую ядро ​​3.16.2 f20 64b

Ссылка на "обходной путь" не работает ... что это? и поддерживает ли это мое ядро ​​... если Торвальдс совершил ошибку в версии 3.14, я подозреваю, что Fedora должна увидеть это в версии 3.16, нет?

+1

+1

+1

+1 Похоже, что все еще происходит в Ubuntu Trusty, 3.13.0-36-generic с Docker версии 1.3.1, сборка 4e9bbfa

+1 также на Trusty. Стоит ли проверять на 14.10, где используется 3.16?

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

Пометить лучших коммиттеров, потому что это смешно. Необходимо публичное обсуждение этого вопроса и признание команды Docker, что эта ошибка может привести к контейнерам или системам, которые периодически ломаются и требуют воссоздания. Я уже знаю нескольких людей, которым приходилось внедрять безумные решения DevOps, такие как периодическое переоснащение своих Docker-хостов каждую неделю или две, потому что их боты сборки имеют очень большой отток. Я представил эту проблему около года назад, и, насколько я могу судить, окончательного решения не было создано, а старые ядра, которые якобы поддерживаются, не поддерживаются.

Команда Docker: проведите исследование, чтобы определить, какие версии ядра используются, почему и какой патч устранит проблему, и задокументируйте ее. Опубликуйте эту информацию вместе с тем, какие версии ядра вы поддерживаете, потому что прямо сейчас потребители Docker снова и снова сталкиваются с этой проблемой, о чем свидетельствует тот факт, что я все еще получаю электронные письма по этой проблеме каждую неделю или две. Серьезно, это серьезная проблема, и она была проблемой еще до версии 1.0.

На мой взгляд, есть несколько возможных вариантов удовлетворительного решения этой проблемы, которые остановили бы получение электронных писем, которые я продолжаю получать за +1 по этой проблеме:

1. Сообщите пользователям, когда Device-Mapper используется в неподдерживаемом ядре, и предоставьте им подробные инструкции о том, как освободить пространство, и, если возможно, автоматически настроить процесс для этого в Docker. Я бы посоветовал, чтобы это уведомление также отправлялось при использовании интерфейса командной строки докера для хоста, который страдает от этой проблемы, чтобы при удаленном управлении хостами из интерфейса командной строки докера пользователи были осведомлены о том, что некоторые хосты могут неправильно освобождать пространство.
2. Устранить проблему (как-нибудь). Я недостаточно знаю о разработке ядра, чтобы понять, что это повлечет за собой, но, основываясь на моем новичке, я предлагаю следующее:

а. Поскольку устройство сопоставления устройств является модулем ядра, внесите его функциональную рабочую версию в дерево исходных кодов Docker как что-то вроде dm-docker

б. Внесите в dm-docker достаточно изменений, чтобы он мог сосуществовать с устройством сопоставления устройств.

c. На затронутых платформах установите модуль ядра dm-docker при установке и по умолчанию используется dm-docker .

1. Внесите изменения в свою документацию по установке и на сайт docker.com, чтобы включить предупреждение о затронутых версиях ядра, и добавьте проверку времени выполнения в пакеты, чтобы проверить правильность работы устройства сопоставления, и, если нет, сообщить об этом пользователю.

Это должно быть проблемой блокировки для следующей стабильной версии Docker, потому что просто неприемлемо продолжать заниматься этим и оставлять пользователей в беде.

Лично я считаю CoreOS единственным стабильным дистрибутивом Linux для Docker (пока эта проблема не будет решена).

Docker Team: Я знаю, что эта проблема не вызвана вашим компонентом, но, пожалуйста, помогите нам использовать ваше программное обеспечение также и в других дистрибутивах Linux. Было бы хорошо, если бы вы также могли упомянуть эту проблему как хорошо известное ограничение Docker в документации, чтобы другие люди не тратили свое время зря.

Благодаря!
Мартин

+1 что-то нужно сделать.

Было бы неплохо, если бы для этой проблемы было что-то более очевидное, чем необходимость копаться в (закрытом) списке проблем github. Потребовалось много времени, чтобы на самом деле обнаружить, что это основная проблема, и было бы неплохо увидеть эту проблему.

Мы, вышестоящие разработчики устройств сопоставления устройств (я и Джо Торнбер) не знали, что эта проблема по-прежнему является проблемой для людей. Мы исправили проблему сразу после того, как узнали о ней (от @alexlarsson еще в декабре 2013 г.) и отметили ее для включения в _все_ стабильные ядра на тот момент, см. Http://git.kernel.org/linus/19fa1a6756ed9e9 ( "dm thin: исправить поддержку отмены для ранее совместно используемого блока")

Джо Торнбер только что узнал, что
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

Итак ... как уже было сказано, пользователи, использующие ядра, которые не имеют восходящего коммита 19fa1a6756ed9e9 («dm thin: fix, discard support to a ранее shared block»), должны исправить это, запустив ядра, которые лучше поддерживаются. Я могу легко отправить сообщение по адресу [email protected], чтобы

В дальнейшем мы хотим, чтобы докер периодически запускал thin_trim на устройстве тонкого пула, которое использует докер. Но мы перейдем через этот мост, когда 'thin_trim' станет широко доступным в дистрибутивах.

@shabbychef @daniellockard нет, AUF не является устаревшим - во-первых, закрыта только одна из этих проблем, и, читаю, я предполагаю, что 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. Докер, который запускают пользователи, также должен включать docker.git commit 0434a2ce от @alexlarsson («devmapper: добавить параметр blkdiscard и отключить его на необработанных устройствах»)

К вашему сведению, при запуске «dmsetup target» будут перечислены целевые версии «тонкого» и «тонкого» пула (при условии, что загружен модуль ядра dm-thin-pool).

Спасибо за внимание к этому. Мы говорили об этом парням из будки на Re: Invent на прошлой неделе.

@snitm, поэтому dmsetup targets нужно добавить к выводу check-config ?

@snitm

Можно ли было бы создать автоматизированный тест, который бы создал устройство сопоставления устройств с тонким предоставлением, выполнял на нем некоторые операции, которые не смогли бы освободить свободное пространство на непропатченном ядре, и сообщать код состояния на основе этого?

@SvenDowideit, вы надеетесь отловить новые ядра,

@AaronFriel кажется чрезвычайно узким, чтобы

Итак, сделав шаг назад, я получил удовольствие от работы в компании, которая понимает, что многоуровневые продукты должны разрабатываться совместно со всеми нижележащими уровнями. И меня мало интересует поддержка тонкой подготовки DM для N произвольных ядер в паре с докером.

И я очень сильно верю, что никто не должен использовать тонкое обеспечение DM с устройствами обратной связи в качестве устройств поддержки. Это был полный взлом, который был объединен с докером без должных ограничений или заботы о том, «как это выглядит в продакшене?».

Я понял, что для правильного развертывания Docker на тонком выделении ресурсов DM требуются функции управления, ориентированные на предприятие, которые предоставляет конфигурация тонкого выделения ресурсов на основе lvm2. Имея это в виду, я постоянно работал над тем, чтобы новое гибридное решение для управления работало, см. Этот PR:
https://github.com/docker/docker/pull/9006

Эта работа зависит от:
1) lvm2> = 2.02.112
2) Целевая версия тонкого пула DM> = v1.14.0 (также известная как изменения, внесенные в linux-next для включения Linux 3.19)

В RHEL7.1 будут эти изменения. И RHELAH (Atomic Host) тоже. Любые другие дистрибутивы / продукты, которые хотят правильно развернуть докер при тонком предоставлении 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 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux

$ sudo версия докера
Версия клиента: 1.3.2
Версия клиентского API: 1.15
Версия Go (клиент): go1.3.3
Git commit (клиент): c78088f / 1.3.2
ОС / Arch (клиент): linux / amd64
Версия сервера: 1.3.2
Версия серверного API: 1.15
Версия Go (сервер): go1.3.3
Git commit (сервер): c78088f / 1.3.2

Я все еще получаю эту ошибку с Ubuntu 14.04 и Docker 1.4.1.

Не рассчитывайте, что тонкие пулы и тонкие версии> = 1.12.0 означают, что все в порядке. Мы запускаем виртуальные машины CentOS 6.5 с ядром 2.6.32-431.29.2.el6.x86_64, а цели dmsetup сообщают, что Тонкий пул и тонкий - это v1.12.0. Однако я застрял с файлом данных размером 40 ГБ, который не освобождается.

Каковы последствия запуска этого на CentOS / RHEL 6.5 с этой ошибкой? Вы в порядке с> = 100 ГБ свободного места? Я предполагаю, что это в конечном итоге заполнит диск любого размера? Или это ограничено 100G?

Имейте в виду, что в версии 6.5 нет новейшего ядра для centos. Я бы порекомендовал простое «yum update» до 6.6 и перезагрузку для тестирования с ядром 2.6.32-504.3.3.

Убедитесь, что самые последние обновления ядра и дистрибутива для CentOS 6 работают нормально и освобождают место.

ripienaar: Можете ли вы явно указать, какую CentOS 6 и версию ядра вы используете? Я просто хочу быть уверенным, что, когда я передам информацию, у меня будет вся необходимая информация.

Благодарю.

Как прокомментировал @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 упоминает, что эту

В настоящее время я использую один из Oracle Enterprise Linux 3.8 UEK.

Есть ли способ обхода этой ситуации? в AWS легко просто воссоздать экземпляр, но в локальной среде разработки нехорошо замечать, что раздел / var на 90% принадлежит устройству-сопоставителю из-за докера; скоро не будет места даже для журналов или журналов

@donrudo, как указано выше - обновление до последней версии centos 6 - ядро ​​504.3.3.

Это нормально для centos, но некоторые из наших разработчиков используют Fedora, а другие OpenSuse.

Все изменения тонкой подготовки DM сначала отправляются восходящим потоком. Таким образом, если Centos 6 фиксируется, он также фиксируется в восходящем направлении. Различным дистрибутивам необходимо более агрессивно откатывать исправления или перебазировать их.

@ripienaar Я спрошу еще раз, знаете ли вы, какая фиксация ядра (или набор коммитов) требуется для исправления?

@lexinator нет

Я вижу эту проблему в Ubuntu 14.04 Trusty и ядре 3.13.0-36-generic. Возможное решение - подключить хранилище AWS EBS к каталогу, чтобы его можно было неограниченно масштабировать.

Ребята, очень болит этот вопрос. CoreOS сейчас переходит на ext4, и скоро у нас тоже будут проблемы с CoreOS.

Как люди могут использовать докер (в dev или prod), если эта проблема не исправлена ​​более года? У всех есть бесконечные диски?

Я считаю, что они переходят на ext4 для оверлея, а не на devmapper. Но это
просто слово на улице ...

В среду, 28 января 2015 г., Сергей [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?

Вся эта ветка довольно нелепа. Один пользователь Debian за другим жалуется. Если вы столкнулись с проблемой, вам следует либо переключиться на дистрибутив, который поддерживается должным образом, либо обратиться к специалистам по сопровождению вашего дистрибутива, чтобы они исправили проблему. Эти дистрибутивы не успевают за исправлениями или улучшениями. Я проигнорирую все будущие мольбы о том, чтобы кто-то исправил эту проблему в дистрибутиве $ 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, и обновление ядра, похоже, устранило проблему использования run away devicemapper.

Тем не менее, спасибо за вашу работу @snitm.

Тем, у кого есть эта проблема в Ubuntu, убедитесь, что вы должным образом очищаете старые образы / контейнеры докеров. Я обнаружил, что мой сценарий очистки не запускается, когда я думал, что это так, и поэтому он занимает так много места.

`` #! / bin / bash

Удалить все контейнеры

докер rm $ (докер ps -a -q)

Удалить все изображения

docker rmi $ (образы докеров -q)
``

@TylerMills отмечает, что docker rm _не_ удаляет тома, созданные контейнерами. Если ваши контейнеры используют тома, вы должны использовать docker rm -v чтобы докер также удалял тома.

@snitm Мы тоже немного поняли это (используя Ubuntu 14.04). Хотя это может быть не вина Docker конкретно, они должны быть сильно заинтересованы в исправлении этого, поскольку это плохо отражается на общем опыте.

Также обратите внимание, что я столкнулся с этой проблемой, и вот что я сделал, чтобы ее исправить:

В моем случае, однако, из-за устройства, на котором / var монтируется при достижении 100% использования, единственный способ остановить хост от паники ядра - это напрямую убить процесс докера (т.е. выполнение любых команд докера вызовет панику).

Затем вручную завершите все процессы, использующие средства монтирования устройства, используя эту команду:

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 в место монтирования с большим пространством и настроить демон docker для использования другого домашнего каталога с помощью аргумента -g

спасибо Александру Ларссону через Адама Миллера

Следуя комментарию @dekz , вероятно, было бы неплохо, если бы руководство по установке не https://docs.docker.com/installation/ubuntulinux/

Спасибо @JohnMorales. Небольшое предупреждение об этом от Docker было бы отличной идеей.

+1

+1

Недавно мы немного разобрались с этим запущенным Ubuntu 14.04.2 LTS (3.16.0-30-generic) и все еще пытаемся найти решение. Похоже, что либо переход на CentOS 6.6 (который предположительно содержит исправление ядра), либо монтирование тома с большим диском - единственные решения.

Кто-нибудь, использующий Ubuntu, нашел приемлемый обходной путь?

Я согласен - Docker должен справиться с этой проблемой - это серьезная ошибка, требующая документации и предупреждающих сообщений, чтобы больше людей не попадались наивно в ту же ловушку.

Я согласен с @natea
У меня такая же проблема с redhat 6.5, и это ставит большой вопросительный знак, готов ли докер к производству, и мы начинаем искать альтернативы.
Я не возражаю даже против того, чтобы вручную решить эту проблему, но сейчас я не знаю ни одного возможного.

@sagiegurarie имейте в виду, что мы повысили требования для CentOS до 6.6 из-за различных проблем с 6.5 (и связанным с ним ядром). Этого требования, вероятно, еще нет на веб-сайте live docs, но оно будет в следующем выпуске, может быть, до этого.

так что вопрос №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

В четверг, 7 мая 2015 г., в 11:26, Dreamcat4 [email protected] написал:

Здравствуйте! Я хотел бы знать, существует ли эта проблема в ubuntu-15.04.
Который сейчас находится в ядре linux-3.19. Большое спасибо.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99968299.

@jfrazelle Ну да ладно. На что это похоже? Вы используете оверлей? Я исходил из предположения (до сих пор), что поддержка оверлеев все еще была экспериментальной, начиная с ядра 3.19.

Да, я использую оверлей :) мы надеемся переместить его вверх по списку в 1.7 lost of us
используйте это и любите это

В четверг, 7 мая 2015 г., Dreamcat4 [email protected] написал:

@jfrazelle https://github.com/jfrazelle Да ладно. На что это похоже? Делать
вы используете оверлей? Я исходил из предположения (до сих пор), что
Поддержка оверлеев была экспериментальной, начиная с ядра 3.19.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/docker/issues/3182#issuecomment -99982543.

@sagiegurari Зачем вам 6.5? Есть ряд обновлений и исправлений, которые вам не хватает из-за того, что вы НЕ переходите на 6.6, включая достойные новостей CVE с именами.

@jperrin, потому что это не мое решение :)
в любом случае я пытаюсь уточнить у всех команд, подойдет ли Redhat 7 для производства.

Кажется, это все еще проблема в CentOS7 (3.10.0-123.el7.x86_64). Я установил новый ящик CentOS и установил докер v1.6.0. Файл данных devicemapper никогда не уменьшается в размере после sudo docker rmi. Я собираюсь получить коробку CentOS6.6, чтобы опробовать ее.

v1.6.0 на Ubuntu 14.04, похоже, дала положительный эффект (по сравнению с v1.5.0)

похоже, также хорошо работает на centos 7, что, я думаю, также можно сказать о redhat 7
но redhat 6.5 - нет, и я предлагаю указать это в документации.

Это должно работать в последнем докере апстрима. И последний комментарий от @sagiegurari, похоже, подразумевает это. (работает на centos 7).

Если это так, мы должны закрыть эту ошибку.

Так эта проблема все еще возникает с последним докером? Если нет, закроем.

ну .... выполнение дополнительных тестов, похоже, дает неопределенные результаты.
Допустим, это намного лучше, но может все еще течь, только намного медленнее.
Я проведу дополнительные проверки для подтверждения.

@sagiegurari

Не могли бы вы дать мне более подробную информацию о том, с какой проблемой вы столкнулись, а также о вашей среде. В заголовке проблемы говорится, что при удалении образа / контейнера пространство не освобождается, и в последнем докере восходящего потока таких проблем не должно быть.

Не могли бы вы взять верхний докер, создать динамический двоичный файл, создать новый тонкий пул (в новом каталоге / var / lib / docker /), вытащить изображение, удалить его и посмотреть информацию о докере и посмотреть, было ли освобождено место или не.

Надеюсь, на следующей неделе я проведу больше тестов, чтобы предоставить более точную информацию.

Признаюсь, я вижу это на нашей машине сборки, где мы создаем и удаляем множество образов (во время самой сборки) + запускаем реестр докеров 2.0 (в который мы всегда отправляем разные изображения с тегом 'latest') + запускаем несколько контейнеров, чтобы провести первоначальное тестирование, чтобы убедиться, что все работает нормально (на самом деле тест не должен запускаться на этой машине, но мы находимся на ранней стадии, поэтому мы создаем / останавливаем / rm много контейнеров).

наши изображения действительно большие, иногда я вижу виртуальный размер более 2 ГБ, поэтому, если есть проблема, он проявляется быстрее, чем с обычными изображениями, которые обычно составляют около 400 мг.

в любом случае, я постараюсь провести несколько тестов, чтобы увидеть поведение и предоставить более подробную информацию на следующей неделе.

Используя Docker версии 1.6.0, соберите 4749651 / 1.6.0 на ядре Linux 3.14.35-28.38.amzn1.x86_64

Удаление образов уменьшает дисковое пространство, требуемое докером.

@vbatts

Можем ли мы закрыть эту проблему? Я не думаю, что в последнем докере у нас есть проблема с освобождением пространства изображения / контейнера из файлов oop. Если возникает что-то конкретное, можно открыть новый выпуск с конкретными деталями.

@rhvgoyal Я не вижу причин спешить и закрывать эту проблему после того, как так много людей жалуются на такое количество платформ / версий.

@sagiegurari

Я не знаю, что мы получаем, оставляя вопрос открытым. Я знаю, что это исправлено в апстриме. Есть так много открытых вопросов. Люди используют их как информационную панель, чтобы отмечать наблюдения.

Я считаю, что оставлять проблему открытой имеет смысл только при наличии реальной воспроизводимой проблемы. В противном случае этот список вопросов продолжает расти, и трудно понять, на чем сосредоточить внимание.

Никто не мешает вам добавлять дополнительные данные к этой проблеме, когда они у вас есть.

@rhvgoyal, какой тег вы имеете в виду в последнем

@rhvgoyal Скажите последний коммит. Я просто клонирую последнее дерево git и проверяю его. Это действительно важно?

Так много проблем сообщается о старых выпусках докеров и старых ядрах. Я думаю, что первым делом нужно проверить, видна ли такая же проблема в последнем докере и относительно новом kernerl. Это дает нам представление о том, осталась ли проблема проблемой или что-то не исправлено в более старых версиях.

Когда кто-то вернется и прочитает это в будущем, да. Я хотел узнать, в какой версии он был исправлен.

Мы выдаем сброс в случае устройств с обратной связью. На самом деле это было сделано давно. Думаю 1.6 должно быть.

@stanislavb тестировал 1.6, и у него это сработало.

Если вы обратитесь к моему первому комментарию в этом выпуске, вы увидите, что я также пробовал с v1.6.0 на centos7, но проблема не исчезла.

@alexDrinkwater

Хорошо, вы можете воспроизвести это? Какой тонкий пул вы использовали (поверх петлевых устройств?). Вы перезапускали докер или это происходит при первом запуске докера?

В некоторых случаях может случиться так, что докер использует устройства цикла, а затем докер перезапускается, может случиться так, что пул не был отключен, потому что какое-то устройство было где-то занято. После перезапуска докера
обнаруживает, что пул уже существует, и не знает, что используются устройства с обратной связью, и не выполняет сброс. Мне интересно, столкнулись ли вы с этой ситуацией?

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

После некоторого докера rmi

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

[root<strong i="18">@b2</strong> ~]# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda2      483443064 9665924 473777140   2% /

@alexDrinkwater

Хорошо, только что я загрузил образ centos7 и попробовал docker 1.6, но не вижу проблемы. Вот шаги.

[ root @ centos7-generic ~] # версия докера
Версия клиента: 1.6.0
Версия клиентского API: 1.18
Версия Go (клиент): go1.4.2
Git commit (клиент): 8aae715 / 1.6.0
ОС / Arch (клиент): linux / amd64
Версия сервера: 1.6.0
Версия серверного API: 1.18
Версия Go (сервер): go1.4.2
Git commit (сервер): 8aae715 / 1.6.0
ОС / Arch (сервер): linux / amd64

Уже импортировано одно изображение.

[ root @ centos7-generic ~] # образы
РЕПОЗИТОРНЫЙ ТЭГ ИД ИЗОБРАЖЕНИЯ СОЗДАН ВИРТУАЛЬНЫЙ РАЗМЕР
docker.io/fedora latest ded7cd95e059 2 недели назад 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 КБ
Всего метаданных: 2,147 ГБ
Доступное пространство для метаданных: 2,147 ГБ
Поддерживается синхронизация Udev: true
Файл цикла данных: / var / lib / docker / devicemapper / devicemapper / data
Файл цикла метаданных: / var / lib / docker / devicemapper / devicemapper / metadata
Версия библиотеки: 1.02.93-RHEL7 (2015-01-28)
Драйвер исполнения: native-0.2
Версия ядра: 3.10.0-229.el7.x86_64
Операционная система: CentOS Linux 7 (Core)
Процессоры: 2

[ root @ centos7-generic ~] # docker rmi fedora
Без тегов: fedora: latest
Удалено: 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: true
Файл цикла данных: / var / lib / docker / devicemapper / devicemapper / data
Файл цикла метаданных: / var / lib / docker / devicemapper / devicemapper / metadata
Версия библиотеки: 1.02.93-RHEL7 (2015-01-28)
Драйвер исполнения: native-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 млн данных

Итак, мой файл цикла фактически сжался после удаления изображения. Думаю, вы на это жалуетесь.

@stanislavb

Вы используете файлы петель? Они не отображаются в информации о докере. Я думаю, вы столкнулись с той же проблемой, когда при запуске докера пул уже был там.

Можете ли вы проверить размер файлов поддержки цикла (/ var / lib / docker / devicemapper / devicemapper / data) и убедиться, что файл сжимается после удаления изображения. (ду-ч).

@rhvgoyal
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

@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. У вас все еще есть проблемы с закрытием этого вопроса?

CentOS 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

После некоторого докера 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 работает.

Я проверил это на новой машине.

Докер версии 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 / докер-хранилище

Можете ли вы попробовать более простой случай сохранения / var в корневом каталоге с файловой системой xfs. Пытаюсь немного сузить проблему.

@alexDrinkwater

Я смонтировал еще один диск с разделом ext4 в / var / lib / docker, чтобы файлы поддержки loopback находились на ext4 (вместо xfs), и у меня все еще работает.

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

На самом деле не уверен, что особенного в вашей настройке.

Чтобы быть конкретным,

• Прежде чем тянуть
  / dev / vdb1 9,8 ГБ 338 МБ 8,9 ГБ 4% / var / lib / docker
• После вытягивания изображения
  / dev / vdb1 9,8 ГБ 544 МБ 8,7 ГБ 6% / var / lib / docker
• После удаления изображения
  / dev / vdb1 9,8 ГБ 338 МБ 8,9 ГБ 4% / var / lib / docker

@alexDrinkwater

Другое важное различие между вашей установкой и моей установкой - это версия ядра. Я использую «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 на / var / lib / docker типа ext3 (rw, relatime, seclabel, data = order)

• Перед вытягиванием изображения
  [ root @ centos7-generic-2 devicemapper] # du -h data
  293 млн данных
• После вытягивания изображения
  [ root @ centos7-generic-2 devicemapper] # du -h data
  501 млн данных
• После удаления изображения
  [ root @ centos7-generic-2 devicemapper] # du -h данные
  501 млн данных

Поэтому по какой-то причине, если файл обратной связи находится в файловой системе ext3, он не работает. Возможно, ext3 достаточно стара, чтобы с ней не работали исключения цикла.

Спасибо, как только я увидел файловую систему ext3, я подумал, что это может быть она. Я думаю, если бы вы смогли воспроизвести проблему на ext3, мы бы закрыли эту проблему. Это будет хорошим ориентиром для других.

Для справки, моими рабочими примерами были Docker 1.6.2 в файловой системе xfs и Docker 1.6.0 и 1.5.0 на ext4.

@vbatts

Можем ли мы закрыть это? Восстановление пространства отлично работает на xfs и ext4. ext3 кажется слишком старым, чтобы его поддерживать.

@rhvgoyal @vbatts IIRC, есть проверка совместимости, которая проверяет базовую файловую систему. Возможно, нам стоит добавить проверку на ext3 если проблема здесь в этом?

редактировать:
для справки; демон / graphdriver / overlay / overlay.go # L115

Драйвер цикла использует fallocate (), чтобы пробить дыру в файле, когда приходит команда discard. Справочная страница Linux для fallocate () проверяет, что она не поддерживается на ext3.

/ *
Не все файловые системы поддерживают FALLOC_FL_PUNCH_HOLE; если файловая система не поддерживает операцию, возвращается ошибка. Операция поддерживается как минимум в следующих файловых системах:
* XFS (начиная с Linux 2.6.38)
* ext4 (начиная с Linux 3.0)
* Btrfs (начиная с Linux 3.7)
* tmpfs (начиная с Linux 3.5)
* /

@thaJeztah

Если кто-то хочет запустить докер на ext3, я думаю, мы должны разрешить это. Просто они не получат поддержку сброса, следовательно, размер файла цикла не будет уменьшаться при удалении образа / контейнеров.

@rhvgoyal как насчет того, чтобы показать это в docker info ? Аналогично выходу Udev Sync Supported .

@thaJeztah

У нас уже есть запись в docker info «Резервная файловая система». Я не уверен, почему там написано extfs вместо того, чтобы точно указать ext2 / ext3 / ext4.

Может быть предупреждение при запуске в логах надо делать здесь. Что-то похожее на предупреждение об использовании петлевых устройств для тонкого пула.

@thaJeztah

И я считаю, что мы должны это делать, только если это затронет множество людей. Если нет, то мы просто создаем больше работы и кода, и, возможно, это того не стоит.

структура syscall.Statfs_t с полем Type на ext2, ext3 и ext4 все возвращает 0xef53 , и это то, что мы используем для обнаружения магии файловой системы.

структура syscall.Statfs_t с полем Type на ext2, ext3 и ext4 возвращает 0xef53, и это то, что мы используем для обнаружения магии файловой системы.

Облом. Было бы хорошо иметь эту информацию, чтобы облегчить выявление проблем, о которых сообщают.

Думаю, тогда мы должны просто закрыть это?

закрытие, так как это проблема с устареванием ext3. Пожалуйста, используйте ext4 или xfs

как вы думаете, это могло бы быть как-то лучше задокументировано в основной документации Docker?

Независимо от того, связана ли проблема с файловой системой или нет, посмотрите, сколько путаницы возникло из-за двух недавних проблем.

Благодарю.

возвращаясь к выпуску # 9786

@dbabits да, я думаю, что упоминание о том, что ext3 имеет некоторые проблемы, стоит упомянуть в документации. Пока не знаю, какое место будет подходящим.

Есть такая же / аналогичная проблема с XFS.
Был на ядре «3.10.0-123.el7.x86_64», но теперь обновлен на «3.10.0-229.el7.x86_64».

Все удалено (контейнер, изображения), но данные по-прежнему содержат 100 ГБ.
Есть идеи, помощь?

[ root @ docker0101 ~] # ls -alh / data / docker / devicemapper / devicemapper /
всего 80G
drwx ------ 2 root root 32 8 июн 16:48.
drwx ------ 5 root root 50 9 июн 07:16 ..
-rw ------- 1 root root 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 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

[ root @ docker0101 ~] # cat / etc / redhat-release
CentOS Linux версии 7.1.1503 (Core)

[ root @ docker0101 ~] # docker ps -a
КОНТЕЙНЕР ИДЕНТИФИКАЦИЯ ИЗОБРАЖЕНИЕ КОМАНДА СОЗДАНО СОСТОЯНИЕ ИМЯ ПОРТОВ

[ root @ docker0101 ~] # образы
РЕПОЗИТОРНЫЙ ТЭГ ИД ИЗОБРАЖЕНИЯ СОЗДАН ВИРТУАЛЬНЫЙ РАЗМЕР

[ 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: true
Файл цикла данных: / data / docker / devicemapper / devicemapper / data
Файл цикла метаданных: / data / docker / devicemapper / devicemapper / metadata
Версия библиотеки: 1.02.93-RHEL7 (2015-01-28)
Драйвер исполнения: native-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-пул: 0 209715200 тонкий пул 7: 1 7: 0 128 32768 1 skip_block_zeroing

[ root @ docker0101 ~] # статус dmsetup
vg1-lvol0: 0 167772160 линейный
docker-253: 0-268599424-пул: 0 209715200 тонкий пул 71359 51606/524288 1306264/1638400 - ro discard_passdown queue_if_no_space

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

[ root @ docker0101 ~] # rpm -qi docker
Имя: докер
Версия: 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 июня 9 08:21 / var / lib / docker -> / data / docker

[ root @ docker0101 ~] # монтировать
/ dev / sda5 на / var типа xfs (rw, relatime, attr2, inode64, noquota)
/ dev / mapper / vg1-lvol0 на / тип данных xfs (rw, relatime, attr2, inode64, noquota)

@tomlux Используемый вами режим loopback devicemapper в основном предназначен для того, чтобы легко поиграть с докером. для серьезной работы возвратная петля будет медленнее и будет иметь некоторые ограничения. Я очень рекомендую прочитать http://www.projectatomic.io/docs/docker-storage-recommendation/

Вы получите лучшую производительность и не столкнетесь с такими вещами, если вы применили все системные обновления.

@tomlux

вы можете добавить "-s" к ls. Это даст вам фактические блоки, выделенные для файлов данных и метаданных. Прямо сейчас он показывает очевидный размер файлов.

Вывод информации docker интригует. Кажется, показывает высокую степень использования.

@tomlux

Таким образом, фактический размер файлов данных и метаданных выглядит маленьким. Вы можете использовать "ls -alsh", чтобы размеры были более удобочитаемыми.

Таким образом, размер файла данных составляет около 79 МБ, а размер файла метаданных - около 202 КБ.

Я думаю, что статистика тонкого пула о количестве используемых блоков не выглядит правильной. Устраняет ли проблему перезагрузка машины?

Я безуспешно перезагружался после обновления ядра.

Итак, файлы цикла большие, и пул считает, что в нем много используемых блоков. Итак, что-то использует эти блоки. Вы можете дать мне вывод?

• докер ps -a
• образы докеров
• ls / var / lib / dokcer / devicemapper / metadata / | wc -l
• выключите докер и запустите следующее.
  thin_dump / var / lib / docker / devicemapper / devicemapper / metadata | grep "device dev_id" | wc -l

Это покажет, сколько тонких устройств находится в пуле.

Хм,
теперь у нас есть МЕРТВЫЕ контейнеры, но нет изображений.
Сделал уже перезагрузку.

Кажется, что-то не так с devicemapper.
Я не хочу спамить эту проблему.
Я также могу «rm -f / var / lib / docker» и перестроить свои контейнеры. Все по сценарию.

сделать "dmsetup status"

Похоже, бассейн в плохом состоянии и, скорее всего, требует ремонта.

Привет,

У меня была такая же проблема под 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 для очистки, хороший параметр cli для отчета о состоянии, а также какой-то мониторинг дискового пространства, поскольку эта проблема возникает у слишком большого количества людей на многих платформах.

@bkeroackdsc @sagiegurari

Причина, по которой я спрашиваю, заключается в том, что потерянные тома не имеют отношения к этой проблеме,
не имеет отношения к devicemapper.

Потерянные тома - это не ошибка , а неправильное представление о том, что тома определены
для контейнера автоматически удаляются при удалении контейнера.
Это _не_ случай (и по замыслу), потому что тома могут содержать данные
это должно сохраниться после удаления контейнера.

_Чтобы удалить том вместе с контейнером_, используйте docker rm -v [mycontainer] .
Будут добавлены функции управления томами (см. Https://github.com/docker/docker/pull/14242 и https://github.com/docker/docker/issues/8363),
и позволит вам управлять "потерянными" томами.

Увеличение размера /var/lib/docker не обязательно является показателем
этот devicemapper теряет данные, потому что размер этого каталога увеличивается
также может быть результатом (потерянных) томов, которые не были очищены
пользователем (докер хранит все свои данные по этому пути).

Я очень надеюсь, что эти 2 предмета дадут необходимые возможности.
Я понял второй пункт, но первый (# 14242) не объясняет вверху, о чем он, кроме того, что это api тома (то есть не уверен, какие возможности он дает).

@sagiegurari это часть требований для реализации управления объемом изображений (есть и другие открытые PR-вопросы). Конечная цель - сделать тома первоклассными в Docker, которые можно создавать / удалять / управлять отдельно от контейнеров, которые их используют.

@swachter Спасибо, что опубликовали этот обходной путь, я восстановил 6 ГБ с помощью вышеупомянутого изображения.

мы исправили проблему утечки тома с помощью грязного взлома, так как он не позволял демону докера запускаться до истечения времени ожидания службы на наших хостах докеров с высоким оттоком:

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

Вы когда-нибудь приходили к выводу, что происходит в коробке CentOS 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 не освобождает дисковое пространство контейнера

boot2docker недавно появился в OS X VirtualBox. OS X полностью исправлена.

Я создаю толстый контейнер (47 ГБ), и у него есть проблема, указывающая на то, что я должен перестроить контейнер. Поэтому я остановил контейнер и сделал docker rm. Двойная проверка с помощью docker ssh'df -h', я обнаружил, что на диске по-прежнему используется 47 ГБ. В контейнере 75 ГБ.

Так что мне нужно снова убить докер-виртуальную машину.

Можем ли мы это сделать?

@ awolfe-silversky - это дисковое пространство внутри виртуальной машины? Если он находится за пределами виртуальной машины, это может быть не связано.

@ awolfe-silversky также; вы тоже удалили _image_? удаление только контейнера может не сильно помочь, если изображение все еще там

@ awolfe-silversky, эта проблема связана с devicemapper - и если вы используете docker-machine / boot2docker, то у вас гораздо больше шансов запустить aufs . Мне также интересно, есть ли у вас docker rmi 'ваше большое изображение.

стоит запустить docker images и docker info чтобы увидеть, действительно ли все так ужасно, как вы говорите :)

(да, если у вас все еще есть виртуальная машина, а изображение удалено, тогда мы должны открыть новую проблему и продолжить отладку, поскольку вы обнаружили странный угловой случай)

Я не снимал изображение. Это из внутреннего реестра докеров.
Я использовал 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 ГиГ.
Докер версии 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 на своем повседневном ноутбуке, и я попробовал докер для обучения, но заполнять свой диск и переустанавливать всю систему не вариант, потому что это не виртуальная машина, и переустановка 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, просто пожирает дисковое пространство, и вы ничего не можете с этим поделать, кроме как удалить / переустановить.

Повторюсь еще раз, чтобы увидеть, что ничего не изменилось. +1

Эта проблема отмечена как закрытая. Нам нужна резолюция. Нет обходного пути, без перенастройки. Каков реальный статус и какие настройки конфигурации задействованы? Удаление и воссоздание рабочего узла Docker недопустимо.

А какая альтернатива? Как нам избежать этого?

Если эту функцию использовать не рекомендуется - почему она молчит и по умолчанию
один? Если вам неинтересны люди, использующие devicemapper - возможно, я буду в порядке
с этим. Но проинформируйте об этом пользователя! Вы понимаете количество
у людей болит голова из-за этого удивительного «обходного пути», который вы выбрали ??
23 июня 2016 года в 16:32 "kpande" [email protected] написал:

обходной путь - избегать использования драйвера docker device-mapper,
К сожалению.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397 или отключить звук
нить
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Всегда есть rkt …

общая стервозная бесполезная язвительность, без сомнения, почему никто из вышестоящих компаний не заботится о том, чтобы дать вам правильные ответы.

никто не заставлял вас использовать Docker.

Это как Oracle говорит Java-разработчику использовать PHP из-за ошибки JVM. Это также не согласуется с лифтом здесь

Три года назад Docker сделал эзотерическую технологию ядра Linux, называемую контейнеризацией, простой и доступной для всех.

Я уверен, что многие люди благодарны за то, что Docker взлетел так, как он сделал, и этого не могло бы произойти без волонтерства сообщества. Тем не менее, не должно быть так сложно признать, что у него тоже есть свои проблемы, без неявного удаления строки «Я участник апстрима, так что заткнись и слушай» всякий раз, когда кто-то поднимает неприятный вопрос.

Подождите. Я сообщил о проблеме, предоставил подробную информацию о моей машине и настройке,
что я не обязан. Ни один из разработчиков не ответил на мою и чужую ошибку
отчеты за полгода. Теперь я констатировал этот факт, вы называете мое поведение
стервозный? У вас вообще открытый исходный код? Я ищу проект Go для работы, и
это не будет Docker, я вам это даю. Это твоя цель?
23 июня 2016 г. в 16:45 "gregory grey" [email protected] написал:

Если эту функцию использовать не рекомендуется - почему она молчит и по умолчанию
один? Если вам неинтересны люди, использующие devicemapper - возможно, я буду в порядке
с этим. Но проинформируйте об этом пользователя! Вы понимаете количество
у людей болит голова из-за этого удивительного «обходного пути», который вы выбрали ??
23 июня 2016 года в 16:32 "kpande" [email protected] написал:

обходной путь - избегать использования драйвера docker device-mapper,
К сожалению.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/3182#issuecomment -228068397,
или отключить поток
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
.

Прежде всего, если у вас все еще есть эта проблема, откройте новый выпуск;

Подождите. Я сообщил о проблеме

Вы ответили на закрытый вопрос трехлетней давности; после обсуждения выше исходная проблема была решена. Ваша проблема _может быть такой же, но для уверенности требуется дополнительное исследование; исправляемые ошибки указывают на то, что на самом деле это может быть что-то еще.

Очень рекомендую открывать новый выпуск, не комментируя закрытый выпуск

предоставил подробную информацию о моей машине и настройке, что я не обязан.

Вы не обязаны делать это, но без какой-либо информации, это вряд ли будет решено. Итак, сообщая об ошибке, включите запрашиваемую информацию в шаблон:
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

Ни один из разработчиков не ответил на мои и другие сообщения об ошибках за полгода.

Если вы имеете в виду «один из сопровождающих», пожалуйста, имейте в виду, что существует почти 24000 выпусков и PR и менее 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)

разрешение

Вы можете освободить место на своем устройстве с помощью стандартных команд докера.

Прочтите 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)

Это должно освободить большую часть скрытого пространства контейнера в devicemapper.

Сдувает докер

Не получилось? Не повезло тебе.

Лучше всего на этом этапе:

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, очистил исходные пакеты, переключился на overlayfs, и теперь все, похоже, работает нормально : https://dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/ (хотя пришлось изменить команду ExecStart для версии docker 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 ... вы купили что-то с открытым исходным кодом?

и вернул это