Moby: 设备映射器不会释放已删除图像中的可用空间

创建于 2013-12-12 · 206评论 · 资料来源: moby/moby

Docker声称通过docker info在删除映像后释放了空间，但是数据文件保持了以前的大小，分配给设备映射器存储后端文件的稀疏文件将继续增长，而不会随着范围的扩大而增长被分配。

我在Ubuntu 13.10上使用lxc-docker：

Linux ergodev-zed 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

此命令序列揭示了问题：

执行docker pull stackbrew/ubuntu:13.10增加了空间使用量，报告了docker info ，之前：

Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-252:0-131308-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb
WARNING: No swap limit support

在docker pull stackbrew/ubuntu:13.10 ：

Containers: 0
Images: 3
Driver: devicemapper
 Pool Name: docker-252:0-131308-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 413.1 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.8 Mb
 Metadata Space Total: 2048.0 Mb
WARNING: No swap limit support

在docker rmi 8f71d74c8cfc ，它返回：

Containers: 0
Images: 0
Driver: devicemapper
 Pool Name: docker-252:0-131308-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb
WARNING: No swap limit support

唯一的问题是，每个stat数据文件已扩展到414MiB（849016 512字节扇区块）。删除映像后，其中的某些空间可以正确重用，但是数据文件永远不会缩小。在某种神秘的条件下（尚无法复制），我分配了291.5 MiB，甚至无法重用。

当安装了0张图片时，我的dmsetup ls看起来像这样：

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

数据文件的du显示如下：

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

我如何拥有docker回收空间，为什么移除图像后docker不自动这样做？

arestoragdevicemapper exexpert kinbug

资料来源

AaronFriel

👍5 😕1

最有用的评论

和我一样，我非常不愿意再次复活这个古老的线程，但是对于在遇到此问题的现有计算机上如何解决此问题，仍然没有有意义的建议。

这是我在tldr上的最大努力；对于整个线程；我希望它可以帮助找到此线程的其他人。

遇到的问题

您的卷有大量（并且正在增长）的空间，该空间在/var/lib/docker并且您正在使用ext3。

解析度

你真倒霉升级文件系统，或在底部看到blowing docker away 。

遇到的问题

您的卷有大量（并且正在增长）的空间，该空间在/var/lib/docker并且您正在_not_使用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)

这应该回收devicemapper中的许多隐藏容器空间。

吹码头走了

没工作吗你真倒霉

此时最好的选择是：

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

这将破坏您所有的docker映像。确保导出您要保持_before_执行此操作的文件。

最终，请阅读https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-production; 但我希望这会帮助其他找到此线程的人。

如果您在使用上述建议时遇到问题，请打开一个新票证，专门解决您遇到的问题并链接到该问题；不要在这里发布。

shadowmint 于 2016-10-27

👍79 ❤6

所有206条评论

+1，我非常想听听有关此主题的讨论。到目前为止，我的策略是

小心构建/拉动
准备吹走/ var / lib / docker：neutral_face：

@AaronFriel ，您正在使用哪个版本的Docker？ 0.7.1？

vreon 于 2013-12-12

👍1

/ cc @regilero （也链接到＃2276）

kiorky 于 2013-12-12

从新的/ 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不会_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

因此，当Thinp设备丢弃一个块时，似乎无法重新分配回送文件。

alexlarsson 于 2013-12-12

但是，如果我在容器fs映像内创建文件，则_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

这使数据文件从299M增加到344M。但是，当我删除a_file.bin（并稍等片刻）后，它又回到了299M。

因此，在我看来，这似乎是一个devicemapper错误。即，它将丢弃从瘦设备转发到基础设备，但是当从池中删除瘦设备时不丢弃。

alexlarsson 于 2013-12-12

这似乎是一个内核问题，我当时正考虑使用BLKDISCARD来解决它，但是我失败了。有关某些详细信息，请参见以下错误： https :

alexlarsson 于 2013-12-16

我将解决方法放在https://github.com/alexlarsson/docker/tree/blkdiscard中，但我们仍在研究是否可以做得更好。

alexlarsson 于 2013-12-17

上游dm关于此问题的评论：
http://device-mapper.org/blog/2013/12/17/thin-provisioning-and-discard-support/

alexlarsson 于 2013-12-17

在具有Docker 0.7.0的CentOS（2.6.32-358.23.2.el6.x86_64）上也存在此问题。很老，但是问题并不仅限于Ubuntu。

blalor 于 2013-12-29

在Arch GNU / Linux 3.12.6-1-ARCH，Docker版本0.7.2上也存在同样的问题。

skakri 于 2014-01-03

在CentOS的0.7.0上仍然存在。

blalor 于 2014-01-07

在Ubuntu 12.04.3 LTS的0.7.2中仍然存在。

docker/devicemapper/devicemapper/data和metadata有很多空间，但在docker/devicemapper/mnt

我得知您可以在docker/devicemapper/mnt/SOME_KIND_OF_ID/rootfs看到容器文件系统真是太好

但是我的硬盘几乎被吃光了，只能由rmdir -r docker修复，这并不是整洁的事情。

nmz787 于 2014-01-09

在为rspec-system编写Docker支持时遇到了类似的问题。我的测试VM（docker主机）有一个8GB的驱动器，并且在反复创建映像而不删除它们之后，我的驱动器已满。但是，删除所有映像和容器后，驱动器仍然100％充满。我认为这是一个ID-10T错误，但只是放弃并一起破坏了VM。

logicminds 于 2014-01-20

在Ubuntu 13.04上仍存在于0.7.5中。

mengzechao 于 2014-01-21

最新合并的PR＃3256已解决此问题。此修复程序将包含在将来的版本中。

我现在要关闭此问题，因为此修复程序已合并到母版中。

unclejack 于 2014-01-21

注意：直到您还使用http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=其中的6d03f6ac888f2cfc9c840db0b965436d32f1816d 。否则，docker修复只是部分。

alexlarsson 于 2014-01-21

👍2

解决空间不足的方法是什么。我正在使用rhel 6.5，可能需要一段时间才能获得新内核。

从我的iPhone发送

2014年1月21日上午6：18，Alexander Larsson [email protected]写道：
注意：直到您还使用http://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=其中的6d03f6ac888f2cfc9c840db0b965436d32f1816d 。否则，docker修复只是部分。
-
直接回复此电子邮件或在GitHub上查看。

logicminds 于 2014-01-21

@logicminds没有超级简单的方法来恢复空间atm。从技术上讲，应该可以手动重新分配回送文件。但是，这将需要将所有未使用的块清零，或者需要进行一些操作以轻松检测稀疏区域，而这在删除瘦设备时不会实现。

alexlarsson 于 2014-01-22

@alexlarsson这是否还会影响OEL 6.5？ OEL 6.5实际上使用uek 3.8 linux内核，由于我可以选择从2.6切换到3.8内核，因此对我来说这可能是一个简单的切换。

logicminds 于 2014-01-22

@logicminds我什至不知道该提交是否在上游内核中。该链接来自设备映射器树。它绝对不在3.8中。

alexlarsson 于 2014-01-22

我正在寻找创建类似fstrim的工具，该工具可用于收回空间。

alexlarsson 于 2014-01-22

👍3

@alexlarsson问题https://bugzilla.redhat.com/show_bug.cgi?id=1043527已关闭，因为“数据不足”。这是否意味着该补丁将不会进入内核？还需要吗？

kontrafiktion 于 2014-04-22

@vrvolle使得

alexlarsson 于 2014-04-22

我仍然在使用默认2.6.32内核的centos 6.5上使用docker 0.9遇到此问题。

我不确定您之前对设备映射器提交的说法是否理解。您能否确认如果我将内核迁移到3.8，则应解决此错误？

提前致谢。

nicolas-van 于 2014-05-02

@ nicolas-van不，您需要此提交： https :

它在3.14中，并且可能在各种3.xy反向端口中

alexlarsson 于 2014-05-05

我之前安装了docker来构建映像并在容器中运行它。然后一段时间后，我清除了所有映像和容器，包括docker应用程序和主文件夹。
现在，我意识到在总共4GB / 24GB可用/已使用（df -h）中，命令du / -sh仅报告了10GB，因此没有考虑另外的10Gb。这可能与docker生成的临时映像的大小相比要小得多，这可能与该错误有关。我用过centos 6.5和docker 0.9。

Jacq 于 2014-05-05

我已经用yum删除了docker，并使用dmsetup从/ dev / mapper / docker *中删除了devs，还删除了rm / var / lib / docker -Rf，仍然使用了df 10gb磁盘报告，但在任何地方都找不到。

Jacq 于 2014-05-24

@Jacq一个可能打开了文件描述符的进程仍可能保留某些文件。你重启了吗？那将确保不会发生。

alexlarsson 于 2014-05-26

我运行Linux 3.14.4-1-ARCH和docker 0.11.1，删除了所有映像和容器。
并且文件/ var / lib / docker / devicemapper / devicemapper只是停留在周围，消耗了约1.5GB

这是我摆弄一些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

Dieterbe 于 2014-06-04

打扰一下，这个错误现在修复了吗？我确实在gentoo中遇到了它。

bolasblack 于 2014-09-03

@bolasblack我运行gentoo并遇到了这个问题。你有发现什么吗？

我正在使用最新的gentoo源，它们是用于x86_64的3.14.14。我看着https://github.com/torvalds/linux/commit/19fa1a6756ed9e92daa9537c03b47d6b55cc2316?diff ，该补丁已应用于我的源代码。我有Docker Docker版本1.1.0，内部版本79812e3。

@alexlarsson感谢您在如此长的时间之后再次将注意力转移到这个已结束的问题上。看来它仍在引起麻烦。关于＃4202的状态有任何疑问吗？

arosboro 于 2014-09-08

这仍然是一个问题！我想我暂时将切换回使用AUFS。

daniellockard 于 2014-09-17

@daniellockard AUFS似乎已被非正式弃用：＃783和＃4704，祝您好运。

shabbychef 于 2014-09-19

Yikes ...那25GB到哪里去了？哦，进入那个文件...。我正在运行内核3.16.2 f20 64b

指向“解决方法”的链接已损坏……这是什么？并且我的内核是否支持它...如果Torvalds在3.14中提交，我怀疑fedora应该在3.16中看到它，否？

ccjon 于 2014-09-23

analytically 于 2014-10-10

Zolmeister 于 2014-10-25

bleib1dj 于 2014-11-04

+1似乎仍在Docker版本1.3.1，版本4e9bbfa的Ubuntu Trusty，3.13.0-36-generic上发生

Crashthatch 于 2014-11-19

在Trusty上也+1。是否值得在使用3.16的14.10上进行检查？

4thAce 于 2014-11-19

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

标记最重要的提交者，因为这很荒谬。需要对此进行公开讨论，并且Docker团队承认此错误可能导致容器或系统定期中断并需要重新创建。我已经知道有几个人必须实施疯狂的devops解决方案，例如每两周定期重新镜像其Docker主机，因为他们的构建bot太多了。我在一年前就介绍了这个问题，据我所知，到目前为止还没有创建确定的解决方案，而且表面上不支持的旧内核也没有。

Docker团队：请进行研究以确定受影响的内核版本，原因以及修复该问题的补丁，并将其记录下来。将这些信息以及您支持的内核版本一起发布，因为现在Docker的消费者一遍又一遍地受到这个问题的困扰，这一事实证明了我仍然每两周都会收到有关此问题的电子邮件。严重的是，这是一个棘手的问题，自1.0以来一直是一个痛苦的问题。

如我所见，有几种可能的方法可以以令人满意的方式解决此问题，这将阻止我不断收到有关此问题的+1电子邮件：

在不支持的内核上使用Device-Mapper时通知用户，并向他们提供有关如何回收空间的详细说明，并在可能的情况下自动在Docker中设置一个执行此操作的过程。我建议当针对遭受此问题的主机使用Docker CLI时，也应发出此通知，以便从Docker CLI远程管理主机时，使用户意识到某些主机可能无法正确回收空间。
解决问题（以某种方式）。我对内核开发了解得不够，不知道这将意味着什么，但是根据我的新手阅读，我建议这样做：

一种。由于设备映射器是一个内核模块，因此将其功能正常的工作版本像dm-docker一样带入Docker源代码树。

b。对dm-docker足够的更改，使其可以与设备映射器共存。

C。在受影响的平台上，在安装时安装dm-docker内核模块，默认使用dm-docker 。

修改您的安装文档和docker.com站点，以在受影响的内核版本上添加警告，并向软件包添加运行时检查以验证设备映射器操作是否正确，如果没有，请向用户报告。

对于Docker的下一个稳定版本来说，这应该是一个阻碍性的问题，因为继续对其进行操作并使用户陷入困境完全是不可接受的。

AaronFriel 于 2014-11-19

👍32

我个人认为CoreOS是Docker的唯一稳定的Linux发行版（直到此问题得到解决）。

Docker团队：我知道这个问题不是由您的组件引起的，但是请帮助我们在其他Linux发行版上也使用您的软件。如果您还可以将此问题作为Docker在文档中的众所周知的限制来提及，那么其他人不会浪费时间。

谢谢！
马丁

damovsky 于 2014-11-19

+1事情需要做。

如果这个问题比不得不深入研究（已关闭的）github问题列表更明显，那就太好了。实际上，花了很长时间才发现这是潜在的问题，因此很容易看到此问题。

adamdecaf 于 2014-11-19

我们上游的Device Mapper开发人员（本人和Joe Thornber）绝对意识到，这个问题仍然是人们的问题。我们一经意识到就解决了该问题（ @alexlarsson早在2013年12月），并在当时将其标记为包含在_all_稳定内核中，请参阅： http ://git.kernel.org/linus/19fa1a6756ed9e9（ “ dm thin：将废弃支持修复到以前共享的块上”）

Joe Thornber刚意识到@alexlarsson在
https://github.com/jthornber/thin-provisioning-tools/commit/8e921580554ed91e84bb68ea32a8c2ea47ad6ff3

所以...所有所说的，正在运行没有上游提交的内核的用户提交19fa1a6756ed9e9（“ dm thin：修复对先前共享块的丢弃支持”）需要通过运行更好支持的内核来解决。我可以轻松地将注释发送到[email protected]，以将修补程序回填到所有没有它的稳定内核。因此，请让我知道哪些稳定内核没有此修复程序。

展望未来，我们将希望docker对docker使用的瘦池设备定期运行'thin_trim'。但是一旦发行版中广泛使用“ thin_trim”，我们将跨越那座桥梁。

snitm 于 2014-11-19

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

SvenDowideit 于 2014-11-19

@snitm您可以在hack/check_config.sh添加一些内容来告诉用户他们的内核没有此补丁吗？

SvenDowideit 于 2014-11-19

不幸的是， @ SvenDowideit的问题更改未在任意内核中识别。对于初学者来说，提交19fa1a6756ed9e9并没有遇到瘦目标或瘦池目标的版本。但是即使这样做，版本也会在所有稳定的内核之间变化（这就是为什么“稳定”提交中的版本颠簸是不好的。因为这是对提交提交到的所有内核进行手工编辑的原因）。

但是，精简池目标版本> 1.12.0的用户都将具有此修复程序。因此内核> = 3.15。用户正在运行的docker还需要包括

snitm 于 2014-11-19

仅供参考，运行“ dmsetup目标”将列出精简和精简池目标版本（前提是已加载dm-thin-pool内核模块）。

snitm 于 2014-11-19

感谢您对此的关注。上周，我们在Re：Invent的展位上提到了它。

dcvii 于 2014-11-19

@snitm，因此dmsetup targets输出添加到check-config输出中？

SvenDowideit 于 2014-11-19

@snitm

是否有可能创建一个自动测试，该测试将创建精简配置的设备映射器设备，对该设备执行一些操作，而这些操作将无法回收未修补内核上的可用空间，并根据该状态报告状态代码？

AaronFriel 于 2014-11-20

@SvenDowideit您是否希望在环回之上开始使用任何DM精简配置之前捕获任何新的令人讨厌的内核？

@AaronFriel的范围似乎非常狭窄，因此无法挂断此特定修复程序。企业级DM精简资源调配的部署要比确保已安装此修复程序多得多（不幸的现实）。自提交19fa1a675进入上游以来，DM精简配置目标已实现了许多错误处理，性能和功能改进。在生产中部署DM精简配置时，所有这些都很重要。

因此，退后一步，我碰巧能够在一家了解分层产品必须与所有基础层一起开发的公司工作。而且我对支持与docker配对的N个任意内核的DM精简配置几乎没有兴趣。

而且，我碰巧地-坚信-没人应该将回送设备作为后备设备使用DM精简配置。那是一个完整的hack，被合并到docker中，而没有适当的约束或担心“这在生产中会是什么样？”。

我已经意识到，在DM精简配置上正确部署docker需要基于lvm2的精简配置配置提供的面向企业的管理功能。因此，考虑到这一点，我一直在努力使新的混合管理解决方案工作，请参阅以下PR：
https://github.com/docker/docker/pull/9006

这项工作取决于：
1）lvm2> = 2.02.112
2）DM精简池目标版本> = v1.14.0（又名针对Linux 3.19包含在linux-next中的更改）

RHEL7.1将进行这些更改。 RHELAH（原子主机）也将。任何其他想要在DM精简配置上正确部署docker的发行版/产品也应如此。

snitm 于 2014-11-20

@snitm是的-我正试图减少因一次断线而遭受打击的用户数量，然后花更多的时间让某人意识到这可能是这种难以理解的痛苦，然后尝试让用户找出来问题是缺少一些神秘的补丁。

所以在您剩余的信息的背景下-我想减少会引起这种令人惊讶的惊喜的内核数量:)

SvenDowideit 于 2014-11-22

@SvenDowideit好的，我在此评论中提供了https :

snitm 于 2014-11-22

@snitm ，@AaronFriel
我在AWS Beantalk，Amazon AMI上遇到了类似问题。
（空间不足）
Linux ip-172-31-63-145 3.14.23-22.44.amzn1.x86_64＃1 SMP Tue Nov 11 23:07:48 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux

$ sudo docker版本
客户端版本：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提交（服务器）：c78088f / 1.3.2

dbabits 于 2014-12-23

我在Ubuntu 14.04和Docker 1.4.1上仍然遇到此错误。

reiz 于 2015-01-06

不要指望瘦池和瘦版本> = 1.12.0表示您还可以。我们正在运行具有2.6.32-431.29.2.el6.x86_64内核的CentOS 6.5 VM，并且dmsetup目标报告精简池和精简版均为v1.12.0。但是，我遇到了一个40GB的数据文件，该文件无法释放自身。

sybrandy 于 2015-01-16

在CentOS / RHEL 6.5上运行此错误有什么含义？ > = 100G的可用空间还可以吗？我认为这最终会填满任何大小的磁盘吗？还是限制在100G？

LinuXY 于 2015-01-17

请记住，6.5没有centos可用的最新内核。我建议对6.6进行简单的“ yum更新”，然后重新启动以测试2.6.32-504.3.3内核。

jperrin 于 2015-01-20

确认CentOS 6的最新内核和发行版更新可以正常工作并释放空间。

ripienaar 于 2015-01-20

ripienaar：您能明确说明您使用的是哪个CentOS 6和内核版本吗？我只是想确保在传递信息时，我拥有所需的所有信息。

谢谢。

sybrandy 于 2015-01-20

正如@reiz在上面评论的那样，这是在最新的Ubuntu 14.04 +最新的

jbiel 于 2015-01-20

基本的操作系统内容：

# 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

在进入该内核之前，它无法恢复空间。

ripienaar 于 2015-01-20

@jperrin提到可以使用centos内核2.6.32-504.3.3解决此问题。是否知道哪个内核提交（提交集？）可以解决此问题？

我当前正在使用Oracle Enterprise Linux 3.8 UEK之一。

lexinator 于 2015-01-21

有没有针对这种情况的解决方法？在AWS上，只需重新创建实例就很容易，但是在本地开发环境中，由于docker，/ var分区由device-mapper拥有90％的所有权并不好。很快就没有空间了，甚至没有日志或日记的空间

donrudo 于 2015-01-27

@donrudo如上所述-更新到最新的centos 6-504.3.3内核。

ripienaar 于 2015-01-27

对于centos来说还可以，但是我们的一些开发人员正在使用Fedora和其他OpenSuse。

donrudo 于 2015-01-27

所有DM精简配置更改都首先发送到上游。因此，如果Centos 6是固定的，它也将固定在上游。各种发行版都需要撤回修复或更积极地调整基础。

snitm 于 2015-01-27

@ripienaar我会再问一次，您知道该修复程序需要哪个内核提交（或一组提交）吗？

lexinator 于 2015-01-27

@lexinator不

ripienaar 于 2015-01-27

我在Ubuntu 14.04 Trusty和内核3.13.0-36-generic上看到此问题。可能的解决方案是将AWS EBS存储附加到目录，以便可以无限扩展。

TylerMills 于 2015-01-27

伙计们，这个问题真的很痛。 CoreOS现在正在迁移到ext4，很快我们在CoreOS上也会遇到所有这些麻烦。

在此问题未解决一年以上的情况下，人们如何使用docker（在dev或prod中）？每个人都有无尽的磁盘吗？

sirocode 于 2015-01-28

我相信他们正在使用ext4进行叠加，而不是devmapper。但是那是
只是街上的话...

2015年1月28日星期三，Sergey [email protected]写道：

伙计们，这个问题真的很痛。现在，CoreOS即将迁移到ext4，
在CoreOS上也会遇到所有这些麻烦。
人们未解决此问题时如何使用docker（在dev或prod中）
一年多了？每个人都有无尽的磁盘吗？
-
直接回复此电子邮件或在GitHub上查看
https://github.com/docker/docker/issues/3182#issuecomment -71800923。

jessfraz 于 2015-01-28

我很迷惑。我在Google实例上的磁盘空间仅为10G，但/ var / lib / docker / devicemapper / devicemapper / data的大小显示为100G。即使删除所有容器和图像，我也无法回收空间。

manjugit 于 2015-02-08

这是一个稀疏文件。使用ls -sh代替ls -l ，或者使用du -h

jperrin 于 2015-02-09

我可以在Ubuntu 13.04上报告此消息（可能不足为奇）。

现在唯一真正的解决方法是提供足够的磁盘空间以预期devicemapper的增长吗？

andrewcstewart 于 2015-02-11

整个线程非常荒谬。一个Debian用户接连抱怨。如果您发现问题，则应切换到已正确维护的发行版，或与发行版维护人员合作以使他们解决此问题。这些发行版无法跟上修复或改进的步伐。我将忽略所有将来有人要求在发行版$ foo上解决此问题的请求，因为该修复显然已经在上游（请参阅CentOS或RHEL）。请针对存在问题的发行版打开错误，并参考此问题。

snitm 于 2015-02-11

当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，内核升级似乎已改善了逃逸的devicemapper使用问题。

无论如何，感谢您的@snitm工作。

dekz 于 2015-02-14

对于那些在Ubuntu上遇到此问题的人，请确保您适当地清理了旧的Docker映像/容器。我发现我的清理脚本在我以为没有运行时就运行了，这就是为什么它占用了太多空间的原因。

```＃！/ bin / bash

删除所有容器

泊坞窗rm $（docker ps -a -q）

删除所有图片

泊坞窗rmi $（泊坞窗图像-q）
```

TylerMills 于 2015-02-18

@TylerMills注意， docker rm不会删除容器创建的卷。如果您的容器使用卷，则应使用docker rm -v来使docker也删除卷。

thaJeztah 于 2015-02-18

@snitm我们也对此

bkeroackdsc 于 2015-02-28

另请注意，我遇到了这个问题，这是我为解决此问题所做的事情：

但是在我的情况下，由于安装了/ var的设备使用率达到100％，阻止主机陷入内核恐慌的唯一方法是直接杀死docker进程（即，发出任何docker命令都会恐慌）。

然后使用以下命令使用devicemapper挂载手动终止所有进程：

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

然后我可以使用以下方法卸载所有devicemapper挂载：

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

这些步骤释放了所有文件描述符，这使我无论如何都可以回收空间/删除文件。

在我的情况下，将/ var / lib / docker目录移动到具有更多空间的挂载并使用-g参数将docker daemon配置为使用其他主目录更有意义。

感谢Alexander Larsson通过Adam Miller

JohnMorales 于 2015-03-02

继续@dekz注释，如果安装指南没有像这样进行安装，不告诉用户没有此修复程序的内核版本是可接受的，则可能是一个好主意： https :

reub 于 2015-04-08

谢谢@JohnMorales。从Docker对此发出一点警告将是一个好主意。

xer0x 于 2015-04-14

ramantalkin 于 2015-04-19

cpoonolly 于 2015-04-29

我们最近对运行Ubuntu 14.04.2 LTS（3.16.0-30通用）的版本有所了解，但仍在努力寻找解决方案。似乎要么切换到CentOS 6.6（应该具有内核修复程序），要么装载具有更大磁盘的卷是唯一的解决方案。

运行Ubuntu的人找到了可接受的解决方法吗？

我同意-Docker应该亲自解决这个问题-这是一个严重的错误，需要文档和警告消息，因此更多的人不会天真地陷入同一陷阱。

natea 于 2015-05-07

我同意@natea
我在redhat 6.5中面临着同样的问题，如果docker已经准备好投入生产并且我们开始寻找替代方案，它将给人们带来一个很大的问号。
我什至不介意获得手动解决方法来解决该问题，但是现在，我还不知道任何可行的解决方法。

sagiegurari 于 2015-05-07

@sagiegurarie请注意，由于6.5（及相关内核）的各种问题，我们将CentOS的要求提高到6.6。此要求可能尚未在在线文档网站上发布，但可能会在下一个版本中发布。

thaJeztah 于 2015-05-07

因此，问题＃11643的答案不相关吗？那意味着我们不能使用redhat 6.5？

sagiegurari 于 2015-05-07

@natea @sagiegurari什么工作对我们来说是手动的“修复”，由@TylerMills建议

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

当然，不利的一面是您必须重新拉动所有图像并再次运行容器。

bkeroackdsc 于 2015-05-07

@bkeroackdsc我记得我之前也删除了所有容器和图像，但是并不能解决问题，但是我会再给它一个镜头。

sagiegurari 于 2015-05-07

你好！我想知道这个问题在ubuntu-15.04上是否仍然存在。现在是linux-3.19内核。非常感谢。

dreamcat4 于 2015-05-07

如果您在使用该内核的ubuntu-15.05上，为什么不使用覆盖，这是一种方法
比devicemapper好

在2015年5月7日星期四上午11：26，Dreamcat4 [email protected]写道：

你好！我想知道这个问题在ubuntu-15.04上是否仍然存在。
现在是linux-3.19内核。非常感谢。
-
直接回复此电子邮件或在GitHub上查看
https://github.com/docker/docker/issues/3182#issuecomment -99968299。

jessfraz 于 2015-05-07

@jfrazelle哦，对。它像什么？您是否使用叠加层？我一直在假设（直到现在），从3.19内核开始，覆盖支持仍处于试验阶段。

dreamcat4 于 2015-05-07

是的，我使用overlay :)我们希望将其在1.7的失踪者名单中上移
使用它并喜欢它

2015年5月7日，星期四，Dreamcat4 [email protected]写道：

@jfrazelle https://github.com/jfrazelle哦，对了。它像什么？做
你用覆盖？我一直在假设（直到现在）
截至3.19内核，overlay支持仍处于试验阶段。
-
直接回复此电子邮件或在GitHub上查看
https://github.com/docker/docker/issues/3182#issuecomment -99982543。

jessfraz 于 2015-05-07

@sagiegurari为什么会坚持使用6.5？您可能会错过许多更新和修复程序，而不必去6.6，包括带有名称的具有新闻价值的CVE。

jperrin 于 2015-05-07

@jperrin，因为这不是我的决定:)
无论如何，我正在尝试与所有团队核实，看看redhat 7是否可以投入生产。

sagiegurari 于 2015-05-12

这似乎在CentOS7（3.10.0-123.el7.x86_64）上仍然是一个问题。我安装了一个新的CentOS机器并安装了docker v1.6.0。在sudo docker rmi之后，devicemapper数据文件不会减小大小。我正在寻找一个CentOS6.6盒子来尝试一下。

alexDrinkwater 于 2015-05-20

Ubuntu 14.04上的v1.6.0似乎起到了积极作用（超过v1.5.0）

Zolmeister 于 2015-05-21

似乎在centos 7上也能很好地工作，我想也可以说是redhat 7
但是redhat 6.5不是，我建议在文档中声明这一点。

sagiegurari 于 2015-06-03

这应该在最新的上游docker中工作。 @sagiegurari的最新评论似乎暗示了这一点。（适用于centos 7）。

如果是这种情况，我们应该关闭此错误。

那么最新的docker是否仍会发生此问题？如果没有，请关闭它。

rhvgoyal 于 2015-06-08

好吧....运行更多测试似乎无法确定结果。
可以说它要好得多，但可能仍在泄漏，只是速度慢了很多。
我会进行更多检查以确认。

sagiegurari 于 2015-06-08

@sagiegurari

您能为我提供更多有关您面临的问题以及您的环境的详细信息。问题的标题是删除映像/容器后不会回收空间，并且最新的上游docker应该没有此类问题。

您能否取上游docker，构建动态二进制文件，创建新的瘦池（在新的/ var / lib / docker /目录中），拉取映像，将其删除并查看docker info并查看是否已释放空间，或者不。

rhvgoyal 于 2015-06-09

我希望下周进行更多测试，以提供更多准确的信息。

我承认我在构建机器中看到了它，在那里我们创建和删除了很多图像（在构建过程中）+运行docker Registry 2.0（我们总是将带有“最新”标签的不同图像推送到其中）+运行少量容器进行初始测试以确保一切正常（测试实际上不应该在该计算机上运行，但是我们处于早期阶段，因此我们创建/停止/管理许多容器）。

我们的图片非常大，有时我看到的虚拟大小超过2gb，因此，如果出现问题，它的显示速度将比通常约为400mg的普通图像更快。

无论如何，我将尝试运行一些测试以查看行为并在下周提供更多详细信息。

sagiegurari 于 2015-06-10

使用Docker版本1.6.0，在Linux内核3.14.35-28.38.amzn1.x86_64上构建4749651 / 1.6.0

删除映像会减少docker占用的磁盘空间。

stanislavb 于 2015-06-10

@vbatts

我们可以解决这个问题吗？我认为在最新的docker中我们没有从oop文件中回收映像/容器空间的问题。如果出现特定的问题，则可以打开一个包含特定详细信息的新期刊。

rhvgoyal 于 2015-06-12

@rhvgoyal在许多人抱怨这么多平台/版本之后，我看不出有急着要解决此问题的原因。

sagiegurari 于 2015-06-12

@sagiegurari

我不知道保持开放状态会获得什么。我知道它固定在上游。有很多问题是未解决的。人们将它们用作仪表板来记录观察结果。

我认为只有在存在真正可复制的问题时，才可以公开解决问题。否则，这个问题清单只会不断增加，并且很难弄清楚应该关注哪个问题。

拥有该数据后，没有人会阻止您向该问题添加更多数据。

rhvgoyal 于 2015-06-12

@rhvgoyal您最近的上游指的是什么标签？

alexDrinkwater 于 2015-06-12

@rhvgoyal说最近一次提交。我只是克隆最新的git树并进行测试。真的有关系吗？

rhvgoyal 于 2015-06-12

在旧的docker版本和旧的内核中报告了很多问题。我认为第一步应该是看看相同的问题在最新的docker和相对较新的kernerl上是否可见。这让我们知道了是否仍然存在问题或旧版本中未解决的问题。

rhvgoyal 于 2015-06-12

是的，当某人回来并将来阅读它时。我想知道它的固定版本。

alexDrinkwater 于 2015-06-12

对于环回设备，我们会发出丢弃信息。实际上早就完成了。我认为1.6应该有它。

rhvgoyal 于 2015-06-12

@stanislavb用1.6进行了测试，它对他

rhvgoyal 于 2015-06-12

如果您在本期中提到我的第一条评论，您会发现我也在centos7上尝试了v1.6.0，仍然遇到了该问题。

alexDrinkwater 于 2015-06-12

@alexDrinkwater

好的，您能够复制它吗？您使用了哪种精简池（在循环设备之上？）。您是否重新启动了docker，或者它是在您第一次启动docker时发生的？

在某些情况下，可能会发生docker使用循环设备然后重新启动docker的情况，这可能是因为某个设备在某处繁忙而未关闭池。重新启动docker
找到该池已经存在，并且不知道正在使用环回设备，并且不会发出丢弃。我想知道你是否遇到过这种情况？

rhvgoyal 于 2015-06-12

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

在一些docker rmi之后

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

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

stanislavb 于 2015-06-12

@alexDrinkwater

好的，刚才我启动了centos7映像并尝试使用docker 1.6，但我没有看到问题。步骤如下。

[ root @ centos7-generic〜 ]
客户端版本：1.6.0
客户端API版本：1.18
Go版本（客户端）：go1.4.2
Git提交（客户）：8aae715 / 1.6.0
操作系统/ Arch（客户端）：linux / amd64
服务器版本：1.6.0
服务器API版本：1.18
Go版本（服务器）：go1.4.2
Git提交（服务器）：8aae715 / 1.6.0
操作系统/存档（服务器）：linux / amd64

已经导入了一张图像。

[ root @ centos7-generic〜 ]
存储库标签图像ID的虚拟尺寸
docker.io/fedora最新ded7cd95e059 2周前186.5 MB

这是docker info的输出。

root @ centos7-generic〜 ]＃码头信息
货柜：0
图片：2
存储驱动程序：devicemapper
池名称：docker-253：1-50331788-pool
池块大小：65.54 kB
支持文件系统：xfs
数据文件：/ dev / loop0
元数据文件：/ dev / loop1
使用的数据空间：525.5 MB
数据空间总计：107.4 GB
可用数据空间：20 GB
使用的中继资料空间：892.9 kB
元数据空间总计：2.147 GB
可用的元数据空间：2.147 GB
支持的Udev Sync：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（核心）
CPU：2

[ root @ centos7-generic〜 ]
未标记： 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 MB
数据空间总计：107.4 GB
可用数据空间：20.22 GB
使用的中继资料空间：733.2 kB
元数据空间总计：2.147 GB
可用的元数据空间：2.147 GB
支持的Udev Sync：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（核心）
CPU：2

注意数据使用量从525MB降至307MB。因此，删除图像确实为我节省了空间。

rhvgoyal 于 2015-06-12

好的，我忘记了在操作前后粘贴循环文件的大小。这里是。

拉图像之前。
$ cd / var / lib / docker / devicemapper / devicemapper
$ du -h数据
293M数据
拉像后
[ root @ centos7-generic devicemapper]
499M数据
删除图像后
[ root @ centos7-generic devicemapper]
293M数据

因此，我的循环文件实际上在图像删除后会缩小。我认为这就是您所抱怨的。

rhvgoyal 于 2015-06-12

@stanislavb

您是否在使用循环文件？它们在您的Docker信息中不可见。我认为您遇到了同样的问题，即当docker启动池已经存在时。

您是否可以检查循环备份文件（/ var / lib / docker / devicemapper / devicemapper / data）的大小，并确保在删除映像后该文件会缩小。（du -h）。

rhvgoyal 于 2015-06-12

@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 于 2015-06-12

@stanislavb

好的，因此循环设备的大小确实在减小。

我也从代码验证。即使重启后docker发现瘦池已经存在，我们也会发出丢弃指令。

    // 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中的数据点。您是否仍然有兴趣解决此问题。

rhvgoyal 于 2015-06-12

CentOS的6.6

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

在一些docker rmi之后

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

[root<strong i="22">@b1</strong> ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda2      475957304 25606060 426167284   6% /
[root<strong i="23">@b1</strong> ~]# du -h /var/lib/docker/devicemapper/devicemapper/data
13G /var/lib/docker/devicemapper/devicemapper/data

stanislavb 于 2015-06-12

好的，所以即使在1.5中也可以。

rhvgoyal 于 2015-06-12

我在新机器上进行了测试。

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

alexDrinkwater 于 2015-06-12

让我知道您的机器或版本等详细信息。

alexDrinkwater 于 2015-06-12

@alexDrinkwater

看起来您正在/ var上安装单独的设备。该设备上的文件系统是什么，安装选项是什么？

rhvgoyal 于 2015-06-12

也可以给我以下。

dmsetup表
dmsetup状态
猫/ etc / sysconfig / docker-storage

rhvgoyal 于 2015-06-12

您能尝试使用xfs文件系统将/ var保留在root本身上的简单情况吗？试图缩小问题的范围。

rhvgoyal 于 2015-06-12

@alexDrinkwater

我在/ var / lib / docker上安装了另一个带有ext4分区的磁盘，以便将环回备份文件放在ext4（而不是xfs）上，并且仍然对我有用。

/ var / lib / docker上的/ dev / vdb1类型ext4（rw，relatime，seclabel，data = ordered）

真的不确定您的设置有什么特别之处。

rhvgoyal 于 2015-06-12

再具体一点，

拉前
/ 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

rhvgoyal 于 2015-06-12

@alexDrinkwater

您的设置和我的设置之间的另一个主要区别是内核版本。我正在使用“ 3.10.0-229.el7.x86_64”，而您似乎正在使用“ 3.10.0-123.el7.x86_64”。您能否升级内核并尝试一下。

rhvgoyal 于 2015-06-12

感谢您的帮助@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=

我没有配置任何自定义存储选项。

alexDrinkwater 于 2015-06-12

找到了。我认为这与ext3文件系统有关。我也可以看到问题。尝试使用其他文件系统，例如ext4或xfs，您将不会遇到问题。

/ var / lib / docker上的/ dev / vdb1类型ext3（rw，relatime，seclabel，data = ordered）

拉前影像
[ root @ centos7-generic-2 devicemapper]
293M数据
拉后图像
[ root @ centos7-generic-2 devicemapper]
501M数据
移除影像后
[ root @ centos7-generic-2 devicemapper]
501M数据

因此，由于某种原因，如果环回文件位于ext3文件系统上，则它将不起作用。可能是ext3已经足够老了，以至于循环丢弃对它不起作用。

rhvgoyal 于 2015-06-12

谢谢，我一看到文件系统是ext3，就以为是这样。我想如果您能够在ext3上重现该问题，那么我们可以将此问题称为已关闭。这将为其他人提供很好的参考。

alexDrinkwater 于 2015-06-12

作为参考，我的工作示例是xfs文件系统上的Docker 1.6.2和ext4上的Docker 1.6.0和1.5.0。

stanislavb 于 2015-06-13

@vbatts

我们可以关闭这个吗？空间回收在xfs和ext4上工作正常。 ext3似乎太旧了，无法支持它。

rhvgoyal 于 2015-06-16

@rhvgoyal @vbatts IIRC，有一个兼容性检查来检查基础文件系统。如果这是这里的问题，也许我们应该为ext3添加一张支票？

编辑：
以供参考; 守护程序/graphdriver/overlay/overlay.go#L115

thaJeztah 于 2015-06-16

丢弃时，循环驱动程序使用fallocate（）在文件中打孔。fallocate（）的Linux手册页验证ext3不支持它。

/ *
并非所有文件系统都支持FALLOC_FL_PUNCH_HOLE；如果文件系统不支持该操作，则返回错误。至少在以下文件系统上支持该操作：
* XFS（自Linux 2.6.38起）
* ext4（从Linux 3.0开始）
* Btrfs（自Linux 3.7起）
* tmpfs（从Linux 3.5开始）
* /

rhvgoyal 于 2015-06-16

@thaJeztah

如果有人想在ext3上运行docker，我想我们应该允许这样做。只是它们不会获得丢弃支持，因此删除图像/容器时循环文件的大小不会缩小。

rhvgoyal 于 2015-06-16

@rhvgoyal如何在docker info显示此内容？与Udev Sync Supported输出类似。

thaJeztah 于 2015-06-16

@thaJeztah

我们已经在docker info“ Backing filesystem”中有一个条目。我不知道为什么说extfs而不是对ext2 / ext3 / ext4精确。

可能是启动时的警告，日志应在此处执行。与警告有关将循环设备用于精简池的警告类似。

rhvgoyal 于 2015-06-16

@thaJeztah

我认为只有在很多人受到此影响的情况下，我们才应该这样做。如果没有，那么我们将创建更多的工作和代码，这可能不值得。

rhvgoyal 于 2015-06-16

syscall.Statfs_t结构体以及ext2，ext3和ext4上的Type字段都返回0xef53 ，这就是我们用来检测文件系统魔术的方法。

vbatts 于 2015-06-16

ext2，ext3和ext4上具有Type字段的syscall.Statfs_t结构都返回0xef53，这就是我们用来检测文件系统魔术的方法。

笨蛋拥有该信息以使其更容易识别报告的问题本来很好。

我想，我们应该关闭它吗？

thaJeztah 于 2015-06-16

关闭，因为这是ext3过时的问题。请使用ext4或xfs

vbatts 于 2015-06-16

您是否认为以某种方式可以更好地记录在主要Docker文档中？

无论问题是否与文件系统有关，请查看这在最近的两个问题中引起了多少混乱。

谢谢。

dbabits 于 2015-06-17

发出问题＃9786

dbabits 于 2015-06-17

@dbabits是的，我认为提及ext3有一些问题可能值得在文档中提及。尚不知道合适的位置。

thaJeztah 于 2015-06-17

与XFS有相同/相似的问题。
在内核“ 3.10.0-123.el7.x86_64”上，但现在在“ 3.10.0-229.el7.x86_64”上进行了更新。

删除所有内容（容器，图像），但数据仍包含100GB。
有什么想法吗？

[ root @ docker0101〜 ]＃ls -alh / data / docker / devicemapper / devicemapper /
总计80G
drwx ------ 2根根32 Jun 8 16:48。
drwx ------ 5 root root 50 Jun 9 07:16 ..
-rw ------- 1 root root 100G Jul 16 21:33 data
-rw ------- 1根root 2.0G Jul 17 09:20元数据

[ root @ docker0101〜 ]
Linux docker0101 3.10.0-229.7.2.el7.x86_64＃1 SMP Tue Jun 23 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux

[ root @ docker0101〜 ]
CentOS Linux版本7.1.1503（核心）

[ root @ docker0101〜 ]
容器ID图像命令创建的状态端口名称

[ root @ docker0101〜 ]
存储库标签图像ID的虚拟尺寸

[ root @ docker0101〜 ]＃码头信息
货柜：0
图片：0
存储驱动程序：devicemapper
池名称：docker-253：0-268599424-pool
池块大小：65.54 kB
支持文件系统：xfs
数据文件：/ dev / loop0
元数据文件：/ dev / loop1
使用的数据空间：85.61 GB
数据空间总计：107.4 GB
可用数据空间：40.91 MB
使用的中继资料空间：211.4 MB
元数据空间总计：2.147 GB
元数据可用空间：40.91 MB
支持的Udev Sync：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（核心）
CPU：4
总内存：11.58 GiB
名称：docker0101

[ root @ docker0101〜 ]＃dmsetup表
vg1-lvol0：0 167772160线性8:16 2048
docker-253：0-268599424-pool：0 209715200瘦池7：1 7：0 128 32768 1 skip_block_zeroing

[ root @ docker0101〜 ]＃dmsetup状态
vg1-lvol0：0 167772160线性
docker-253：0-268599424-pool：0 209715200瘦池71359 51606/524288 1306264/1638400-ro throw_passdown queue_if_no_space

[ root @ docker0101〜 ]
DOCKER_STORAGE_OPTIONS =

[ root @ docker0101〜 ]
名称：码头工人
版本：1.6.2
发布：14.el7.centos
架构：x86_64
安装日期：CEST 2015年7月17日星期五09:19:54
组：未指定
尺寸：33825026
许可：ASL 2.0
签名：RSA / SHA256，2015年6月24日星期三05:43:12 CEST，密钥ID 24c6a8a7f4a80eb5
源RPM：docker-1.6.2-14.el7.centos.src.rpm
建立日期：CEST 2015年6月24日星期三03:52:32
构建主机：worker1.bsys.centos.org

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

[ root @ docker0101〜 ]＃挂载
/ var / xfs上的/ dev / sda5（rw，relatime，attr2，inode64，noquota）
/数据类型xfs上的/ dev / mapper / vg1-lvol0（rw，relatime，attr2，inode64，noquota）

tomlux 于 2015-07-17

@tomlux您正在使用的devicemapper回送模式主要是为了轻松地与http://www.projectatomic.io/docs/docker-storage-recommendation/

假设您已经应用了所有系统更新，您将获得更好的性能，并且不会遇到此类问题。

jperrin 于 2015-07-17

👍1

@tomlux

您可以在ls中添加“ -s”吗？这将为您提供分配给数据和元数据文件的实际块。现在，它正在显示文件的明显大小。

码头工人的信息输出虽然很有趣。它似乎显示出很高的使用率。

rhvgoyal 于 2015-07-17

ocr

tomlux 于 2015-07-17

@tomlux

因此，数据和元数据文件的实际大小看起来很小。您可以使用“ ls -alsh”，以使大小更易读。

因此，数据文件大小似乎约为79MB，元数据文件大小约为202KB。

我认为瘦池有关使用的块数的统计信息看起来不正确。重新启动计算机是否可以解决问题？

rhvgoyal 于 2015-07-17

内核更新后我没有重新启动。

tomlux 于 2015-07-17

好的，因此循环文件很大，pool认为它有很多已用块。所以有些东西正在使用那些块。你能给我输出吗？

码头工人ps -a
码头工人图像
ls / var / lib / dokcer / devicemapper / metadata / | wc -l
关闭docker并运行以下命令。
thin_dump / var / lib / docker / devicemapper / devicemapper /元数据| grep“设备dev_id” | wc -l

这将告诉您池中有多少个瘦设备。

rhvgoyal 于 2015-07-17

嗯，
现在我们有了DEAD容器，但没有图像。
已经重启了。

devicemapper似乎有问题。
我不想向这个问题发送垃圾邮件。
我还可以“ rm -f / var / lib / docker”并重建我的容器。一切都按照脚本编写。

tomlux 于 2015-07-17

做“ dmsetup状态”

看起来游泳池状况不好，很可能需要维修。

rhvgoyal 于 2015-07-17

tomlux 于 2015-07-17

你好

在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

释放了大量的磁盘空间。

swachter 于 2015-08-17

👍4

这没有任何有意义的方式解决。在最新的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 于 2015-08-17

😕1

@bkeroackdsc该空间还可以与“孤立”卷相关吗？

thaJeztah 于 2015-08-17

我同意@bkeroackdsc，这没有解决。
我问@rhvgoyal，为什么他要这么多结案。
最后，由于这个问题，我从docker退出了。
它正在杀死该产品。

成为孤儿还是没有成为孤儿，没有良好，简便的方法来清理空间。
需要有一个用于清理的docker cli选项，一个良好的状态报告cli选项以及对磁盘空间的某种监视，因为此问题发生在许多平台上的太多人身上。

sagiegurari 于 2015-08-18

@bkeroackdsc @sagiegurari

原因我问的是失去父母的卷没有涉及到这个问题，
不相关的devicemapper。

孤立卷不是错误，而是误解了已定义卷
删除容器时，将自动删除该容器的。
并非如此（根据设计），因为卷可以包含数据
删除容器后应该仍然存在。

_要与容器一起删除卷，请使用docker rm -v [mycontainer] 。
将添加卷管理功能（请参阅https://github.com/docker/docker/pull/14242和https://github.com/docker/docker/issues/8363），
并允许您管理“孤立”卷。

的规模不断壮大/var/lib/docker不必是一个迹象
该设备映射器正在泄漏数据，因为该目录的大小增加了
也可能是尚未清理的（孤立）卷的结果
由用户（码头工人将其所有数据存储在该路径中）。

thaJeztah 于 2015-08-18

我真的希望这两个项目能够提供所需的功能。
我确实理解了第二个项目，但是第一个项目（＃14242）并没有在顶部解释卷api的含义（意思是，不确定其提供的功能）。

sagiegurari 于 2015-08-18

@sagiegurari是实现图像量管理的要求的一部分（还有其他一些开放式PR的问题）。最终目标是使卷成为Docker中的一等公民，可以独立于使用它们的容器来创建/删除/管理它们。

thaJeztah 于 2015-08-18

@swachter感谢您发布该解决方法，我使用上述图像回收了6GB。

rxacevedo 于 2015-08-18

我们用肮脏的黑客解决了泄漏量问题，因为它阻止了docker守护进程在服务超时之前在高流量的docker主机上启动：

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

解决了该问题而无需刷新预缓存的图像。

nathwill 于 2015-08-18

😄1

我们可以在另一期中讨论泄漏量的问题。在这里讨论它给人的印象是它是设备映射器问题，而实际上不是。

rhvgoyal 于 2015-08-25

@tomlux @rhvgoyal

您是否曾经就CentOS 7包装盒中的情况得出结论？我的Docker主机几乎完全相同，并且遇到了相同的问题。我一直讲到@rhvgoyal要求运行thin_dump命令。之后，我去启动docker守护程序，但它无法启动。从那时起，我刚刚删除了/ 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

brian-dlee 于 2015-10-27

@tomlux @rhvgoyal

我找到了问题的根源。尽管它看起来如何，但与线程中的问题无关。这仅仅是由于对Docker工作方式的误解。所有，死容器仍保留它们在执行期间分配的磁盘空间。我只需要卸下所有的容器外壳即可释放磁盘空间。我确实记得这个线程中出现了这个问题，但是我认为它仅被视为已安装的卷，而不是容器分配的磁盘空间。

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

@tomlux这也是您的问题，因为您的docker ps -a显示了几个Dead容器。

brian-dlee 于 2015-10-29

docker rm没有释放容器的磁盘空间

最新的OS X VirtualBox中的boot2docker。 OS X已完全修补。

我正在构建一个胖（47 GB）的容器，但出现问题，表明我应该重建该容器。所以我停止了容器并做了docker rm。使用docker ssh进行双重检查'df -h'，我发现磁盘使用率仍为47 GB。容器有75 GB。

因此，我将需要再次杀死Docker VM。

我们能做到吗？

awolfe-silversky 于 2016-01-29

@ awolfe-silversky VM返回了磁盘空间_inside_吗？如果它在VM外部，则可能无关。

thaJeztah 于 2016-01-29

@ awolfe-silversky也; 您也删除了_image_吗？如果图像仍然存在，仅移除容器可能无济于事

thaJeztah 于 2016-01-29

@ awolfe-silversky这个问题与devicemapper有关-如果您使用的是docker-machine / boot2docker，那么您更有可能正在运行aufs 。我也想知道您是否有docker rmi的大形象。

运行docker images和docker info ，看事情是否真的像您听起来那样可怕：)

（是的，如果您仍然有虚拟机，并且已删除映像，那么我们应该打开一个新问题并进行进一步调试，因为您发现了一个奇怪的极端情况）

SvenDowideit 于 2016-01-29

我没有删除图像。它来自内部docker注册表。
我使用awk脚本来调整图像大小-总计6.9 GB。

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

它很脏，但是我知道所有图像大小都以MB为单位。

这是我尝试诊断使用情况的方法：

 file:///Andrew-Wolfe-MacBook-Pro.local/Users/awolfe/DataStores
awolfe_10063: docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

 file:///Andrew-Wolfe-MacBook-Pro.local/Users/awolfe/DataStores
awolfe_10064: docker-machine ssh 'awolfe-dbhost' 'df -h'
Filesystem                Size      Used Available Use% Mounted on
tmpfs                     7.0G    123.8M      6.9G   2% /
tmpfs                     3.9G         0      3.9G   0% /dev/shm
/dev/sda1                71.0G     47.2G     20.2G  70% /mnt/sda1
cgroup                    3.9G         0      3.9G   0% /sys/fs/cgroup
none                    464.8G    379.9G     84.8G  82% /Users
/dev/sda1                71.0G     47.2G     20.2G  70% /mnt/sda1/var/lib/docker/aufs

awolfe-silversky 于 2016-01-29

现在我有0张图像的盒子。
docker volume ls -qf dangling=true显示任何内容。
docker volume ls显示了很多卷，根据定义，这些卷是孤立的，因为没有图像可以拥有它们。
docker volume rm $(docker volume ls)显示了很多这样的消息：

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

设备映射器目录占用30 GiG。
Docker版本1.10.2，内部版本c3959b1
CentOS 7，3.10.0-327.10.1.el7.x86_64

ror6ax 于 2016-03-14

👍2

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)

另外，为什么默认安装使用“强烈建议”存储选项？
为什么在安装时没有告诉我？

ror6ax 于 2016-03-14

我在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

在我定期安装新的docker映像的实例上，唯一的解决方案是执行以下操作：

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

ir-fuel 于 2016-04-23

👍20

由于这个错误已经存在多年了，而且似乎还没有关闭，您能不能在docker文档中找到有关devidemapper如何破坏安全性的所有docker信息？
我的意思是，在此页面中： https :
放置诸如“清洁设备映射器”之类的内容以及操作方法。

我将尝试执行rm -rf / var / lib / docker，但是我对此感到不舒服。有人可以告诉我是否安全吗？

我在日常笔记本电脑中使用gentoo linux，尝试使用docker进行学习，但由于无法安装虚拟机并重新安装gentoo需要时间，因此无法填充磁盘并重新安装整个系统。

感谢您的工作。

mercuriete 于 2016-05-21

👍8

@mercuriete在您的开发机器上，只需卸载

ir-fuel 于 2016-05-21

👎22 😕7 👍3 ❤1 🎉1

@ 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

aleks-f 于 2016-05-22

我正在使用service docker start

ir-fuel 于 2016-05-22

👍2

@ ir-fuel谢谢，它工作正常。：+1：

mercuriete 于 2016-05-27

寻找此问题的解决方案时，重新安装docker释放磁盘空间是我最荒谬的答案。不仅浪费时间，而且在大多数环境中甚至都不允许这样做。如果您是小时工，这是获得报酬的好方法。

asarkar 于 2016-06-22

👍19 ❤2

我完全同意。令人惊奇的是，像Docker这样的产品只是不断地吞噬磁盘空间，除了卸载/重新安装之外，您无能为力。

ir-fuel 于 2016-06-23

👍2

再次检查此问题后，没有发现任何更改。 +1

ror6ax 于 2016-06-23

该问题被标记为已关闭。我们需要一个解决方案。没有解决方法，没有重新配置。什么是真实状态？涉及哪些配置设置？删除并重新创建生产Docker节点是不可接受的。

awolfe-silversky 于 2016-06-23

👍7

还有什么选择？我们如何避免这种情况？

ir-fuel 于 2016-06-23

如果不推荐使用此功能-为什么它是静音且默认的
一？如果您不关心使用devicemapper的人-我什至可以
有了这个。但是一定要通知用户！你知道吗
人们因您选择了这种惊人的“解决方法”而感到头痛？？
在2016年6月23日下午4:32，“ kpande” [email protected]写道：

解决方法是避免使用docker device-mapper驱动程序，
不幸。
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/docker/docker/issues/3182#issuecomment -228068397或静音
线程
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
。

ror6ax 于 2016-06-23

👍6 👎3

总是有rkt …

blalor 于 2016-06-23

👍6

毫无头绪的蛇行毫无疑问是为什么为什么上游没人会给你适当的答案。

ripienaar 于 2016-06-23

没有人强迫您使用Docker。

就像Oracle告诉Java开发人员由于JVM错误而使用PHP。这也与这里的电梯间距不一致

三年前，Docker使一种深奥的Linux内核技术（称为容器化）变得简单，每个人都可以使用。

我敢肯定，很多人都对Docker的发展如此感激，如果没有社区的自愿，这是不可能发生的。但是，应该毫不费力地承认，每当有人提出令人讨厌的观点时，不隐含地删除“我是上游贡献者，请闭嘴并倾听”这句话，它也存在问题。

asarkar 于 2016-06-24

👍20 🎉4

等待。我确实报告了一个问题，并提供了我的机器和设置的详细信息，
我没有义务。 devteam均未响应我和其他人的错误
报告半年内。现在我说了这个事实，你称我的行为
讨厌吗您甚至开源吗？我正在寻找Go项目以进行工作，并且
不会是Docker，我给你。这是你的目标吗？
2016年6月23日16:45，“格雷戈里·格雷”

如果不推荐使用此功能-为什么它是静音且默认的
一？如果您不关心使用devicemapper的人-我什至可以
有了这个。但是一定要通知用户！你知道吗
人们因您选择了这种惊人的“解决方法”而感到头痛？？
在2016年6月23日下午4:32，“ kpande” [email protected]写道：
解决方法是避免使用docker device-mapper驱动程序，
不幸。
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/docker/docker/issues/3182#issuecomment -228068397，
或使线程静音
https://github.com/notifications/unsubscribe/ACRlBbL5BDn3qMzUW_UiaALB32anUER4ks5qOpkJgaJpZM4BTlBd
。

ror6ax 于 2016-06-24

👎8 👍2

首先，如果您仍然遇到此问题，请打开一个新的问题；

等待。我确实报告了一个问题

您回答了3年的封闭问题；经过上述讨论，原始问题已解决。您的问题可能相同，但需要更多研究才能确定；您输入的错误表明它实际上可能是其他东西。

我真的建议您打开一个新期刊，而不要评论已结束的期刊

提供了我的机器和设置的详细信息，我没有义务。

您不是必须这样做，但是如果没有任何信息可以解决，就不可能解决。因此，在报告错误时，请在模板中包含要求的信息：
https://raw.githubusercontent.com/docker/docker/master/.github/ISSUE_TEMPLATE.md

在半年的时间内，devteam均未响应我和其他人的错误报告。

如果您是“维护者之一”，请记住，几乎有24000个问题和PR，维护者不到20个，其中许多人除了日常工作外还这样做。并非所有评论都会引起注意，尤其是在已解决的问题上。

如果不推荐使用此功能-为什么它是静音且默认的？

如果不支持_aufs _，_ btrfs_和_zfs_，则为默认设置，您可以找到选择驱动程序时使用的优先级。请参阅daemon / graphdriver / driver_linux.go 。它仍然位于叠加层之上，因为不幸的是，该驱动程序还存在一些其他问题，某些人可能会受到影响。

自动选择一个graphdriver只是为了“让事情运行”。 _your_情况的最佳驱动程序取决于_your_用例。 Docker无法自动做出该决定，因此这取决于用户进行配置。

如果您不关心使用devicemapper的人-我什至可以接受。

回顾上面的讨论，我看到上游devicemapper维护者已经研究了这个“多遍”，试图帮助用户报告这些问题，并解决了该问题。对于报告该问题的人员，此问题已解决，或者在某些情况下，取决于发行版更新devicemapper版本。我不认为这可以视为“不关心”。

另外，为什么默认安装使用“强烈建议”存储选项？

在循环设备上运行非常适合使docker运行，并且这是当前自动设置devicemapper的唯一方法。为了进行生产并总体上获得更好的性能，请使用Direct-lvm，如存储驱动程序用户指南的devicemapper部分中所述。

为什么在安装时没有告诉我？

确实，这超出了安装范围。如果要在生产中使用某些软件，则应该合理地假设您已熟悉该软件，并知道为您的用例进行设置需要什么。一些维护者甚至争辩说是否应该发出警告。 Linux不是“牵手”操作系统（您的发行版是否显示警告，如果您使用RAID-0可能会发生数据丢失？如果您的防火墙中打开了端口？）

thaJeztah 于 2016-06-24

👍32 👎3

和我一样，我非常不愿意再次复活这个古老的线程，但是对于在遇到此问题的现有计算机上如何解决此问题，仍然没有有意义的建议。

这是我在tldr上的最大努力；对于整个线程；我希望它可以帮助找到此线程的其他人。

遇到的问题

您的卷有大量（并且正在增长）的空间，该空间在/var/lib/docker并且您正在使用ext3。

解析度

你真倒霉升级文件系统，或在底部看到blowing docker away 。

遇到的问题

您的卷有大量（并且正在增长）的空间，该空间在/var/lib/docker并且您正在_not_使用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)

这应该回收devicemapper中的许多隐藏容器空间。

吹码头走了

没工作吗你真倒霉

此时最好的选择是：

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

这将破坏您所有的docker映像。确保导出您要保持_before_执行此操作的文件。

最终，请阅读https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#configure -direct-lvm-mode-for-production; 但我希望这会帮助其他找到此线程的人。

如果您在使用上述建议时遇到问题，请打开一个新票证，专门解决您遇到的问题并链接到该问题；不要在这里发布。

shadowmint 于 2016-10-27

👍79 ❤6

rm -rf / var / lib / docker

您也可以使用nuke-graph-directory.sh 。

gg7 于 2016-11-04

👍8

如上所述删除文件后，我无法再启动Docker：
3月2日04:53:40 pmdc001b dockerd [29522]：启动守护程序时出错：初始化graphdriver时出错：打开/ var / lib / docker / devicemapper / devicemapper / data：没有此类文件或目录

gdring2 于 2017-03-02

刚在CentOS 7.3上遇到此问题，并且不想调试存在3年以上的devmapper问题，所以我遵循了此DC / OS指南，清除了原始软件包，切换到overlayfs，现在一切似乎都可以正常工作：https://dcos.io/docs/1.7/administration/installing/custom/system-requirements/install-docker-centos/（必须通过docker版本17.03修改ExecStart命令->“ 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中的内容会导致

pauvos 于 2017-03-21

运行docker system prune释放了我机器上的大量空间。

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

invisibleroads 于 2017-10-28

👍5

好吧，这有点... la脚。

就我而言，卸载Docker并删除/var/lib/docker目录后，我发现了此问题，因此我无法运行等效于service docker stop ... service docker start 。

我发现我的系统没有报告删除已释放的/var/lib/docker的空间（我有大约14 GB的空间，看起来像是一片混乱）。

解决此问题的方法是简单地重新加载文件系统，就我而言，我刚刚重新启动并回收了空间。

Noah-Huppert 于 2018-04-05

我不敢相信这仍然是一个问题！来吧，我仍然有

shahaf600 于 2019-01-21

👍8 😕2

@ shahaf600您正在运行什么版本的https://github.com/moby/moby/issues/3182#issuecomment -228298975

没有细节，您的情况就没什么可说的。您的案件可能是由其他问题引起的，但结果相似。

thaJeztah 于 2019-01-21

好

liusi123 于 2020-10-19

在购买了这些垃圾之一并看到支持状态后，我将其退回。

misterbigstuff 于 2020-10-19

😄1 👎1

@misterbigstuff是您的第一个问题...您购买了开源的东西？

darkpixel 于 2020-10-19

😄1

并退还

misterbigstuff 于 2020-10-19

此页面是否有帮助？

0 / 5 - 0 等级

Moby: 设备映射器不会释放已删除图像中的可用空间

最有用的评论

遇到的问题

解析度

遇到的问题

解析度

吹码头走了

所有206条评论

删除所有容器

删除所有图片

CentOS的7

图像清理之前

在一些docker rmi之后

CentOS的6.6

图像清理之前

检查剩余1929张图像时数据文件的大小

在一些docker rmi之后

遇到的问题

解析度

遇到的问题

解析度

吹码头走了

相关问题