|
 来源：知行并重 / 原文链接引言在往下看时，建议先用docker info检查下你的 docker 信息是不是与下面的保持一致。 Storage Driver: overlay2
Backing Filesystem: xfs
Supports d_type: true
- 如果是，那么恭喜你幸运的避开了一个坑。具体什么坑，下面细说。
1. 掉坑经过事情起因是我的 docker 拉取镜像没有问题，但在起容器时一直报下面的错： docker error creating overlay mount to xxx invalid argument 这让我很困惑，重装 docker 之后也不行。 2. 定位问题2.1 现有'失效'方案于是我就开始上网找解决方案，网上大概有以下几种： - 在 daemon.json 中添加 “storage-driver”:“overlay”
- 在 daemon.json 中添加 “storage-driver”:“devicemapper”
但上面的三个方案 全不靠谱。 不过事后来看，通常你们改成 devicemapper应该就可以勉强”解决问题“了。但不幸也幸运的是我没有成功，正好也能让我从根本上解决问题，填平这个坑。 2.2 定位经过我通过 debug 模式查看原因 # 查看原因
sudo dockerd --debug
 发现是我镜像同时存在 devicemapper 和overlay两种，需要清理一种。  我选择删除 devicemapper （很遗憾我选错了）。 上面的问题又出现了。继续上网找答案，终于在官方文档中发现原因。官方文档中提到： the overlay and overlay2 drivers are supported on xfs backing filesystems, but only with d_type=true enabled
也就是说，用overlay2驱动，必须是以 xfs 作为后端的文件系统。 此外,官方说推荐用overlay2 代替 overlay 和devicemapper（18.09 版本中废除）以获得更高的效率和磁盘 inode 的节省. 这就是我说上面三种方案不靠谱的原因。  2.3 明确原因- 查看 docker info 看到 docker info 中的 Backing Filesystem 异常
<unknown>
 2. 查看磁盘占用
# 查看磁盘位置
sudo blkid
目标磁盘 /dev/sdc1 的文件系统格式竟是ntfs. 终于找到问题的根源了： 磁盘文件系统原因，导致 Docker 的存储驱动（storage-driver）与后端文件系统（Backing Filesystem） 不匹配 3 解决方案既然定位了问题，那么解决办法就很清晰了:
注：XFS是一个64位文件系统，极具伸缩性，非常健壮.2000年被 Linux 系统支持. 3.1. 格式化磁盘,更改文件系统为xfssudo mkfs.xfs /dev/sdc1
3.2. 挂载磁盘# 切换管理员
sudo -i
mount /dev/sdc1 /media/kevin/storage2
# 设置开机自动挂载：
vi /etc/fstab
修改内容如下： 3.3. 修改daemon.json 配置文件将镜像存储位置修改为挂载磁盘 {
'graph':'/media/kevin/storage2/docker/images_data',
}
重启 docker sudo systemctl daemon-reload
sudo systemctl restart docker
检验结果检查 docker info已经变成文章开头的形式，确认没有问题。 启动容器启动成功，解决问题。 总结对于开篇的问题，如果你答案是不一致，那么不建议采用 overlay2 之外的驱动。同时最好将镜像存放在 xfs磁盘上，不行的话 ext4上也也行。 复盘整个问题的产生。其实早在主机刚到家的时候，这个坑我便挖好了：当时装了ubuntu 和 win10 双系统， 两块主力硬盘，却都是在 windows下格式化和挂载的，对应的文件系统格式是 ntfs。而主要用的却是在 ubuntu 使用docker，当时将 “storage-driver” 改成 “devicemapper”，算是临时解决问题。借着这个机会，索性彻底解决了。抬眼窗外，不得不感叹， 出来混迟早要还的！
|
