这是在docker v1.10.3版本的使用过程中，使用convoy 作为volume driver，在一次docker volume remove失败时，使我不得不对docker volume 的源码做一次分析。

问题现象：创建曾删除过的volume会失败，请求无报错返回 重现过程：

• 创建容器，volume使用test5_volume
• 删除容器，删除volume
• 再次创建同名volume时失败

当时有一个Workaround 方案： 通过 convoy 在该宿主机上创建一个同名的 volume （大小任意），然后再次执行 docker volume rm 删除该 volume ； 接着就可以通过 docker volume create 重新创建 volume 了。 当时考虑是 docker 缓存没有及时清理的问题，于是得去分析下相关代码。

##docker volume create源码分析：

看流程图发现 - create时，会触发未注册driver的重新注册，只检查该volume是否在docker daemon缓存中，如果在就不创建。而不会调用convoy接口去确认该volume是否真的存在。如果此时，convoy和docker daemon缓存信息不同步，则create操作不能如愿了。

##docker volume remove源码分析：

看流程图发现 - remove时，只会删除docker daemon缓存中记录的volume信息，不会同步docker dameon和convoy的volume信息。如果此时convoy 中volume数据和docker daemon 缓存中volume数据不一致，也不会得到纠正。

##docker volume list源码分析：

看流程图发现 - list时，如果convoy中记录了某个volume，但docker daemon缓存中没有该volume，则会将该volume信息从convoy同步到docker daemon。

##问题定位 ###docker volume delete的代码 ###docker volume list的代码 第一幅图中可见，每次删除某个volume的时候，会先对这个volume的name加锁，然后vd.Remove(v)函数调用convoy删除这个volume，再清理掉docker的缓存。

第二幅图中可见，每次调用list接口时，List会先调用s.list()函数，该list()函数并不受锁单个volume的锁限制，s.list()函数中会调用convoy拿到所有的volume，然后List方法中会for循环每个volume，先对volume的name加锁，如果volume在缓存中不存在，则加入到缓存。

我们的这个问题的发生的原因：s.list()找convoy拿到所有volume是不受锁的限制的，而且list会for循环处理所有的volume，时间比较长，这就导致这样一种情况：list先拿到convoy的某个volume，然后docker才接到了删除这个volume的请求，docker删除convoy的这个volume并把自己的缓存删掉，然后list中的for循环才处理到这个volume，发现缓存中已经没有这个volume了，于是又把这个volume加入到缓存中（s.setNamed(v, "")），这样就导致缓存convoy端的volume已经清除了，但缓存中还有这个volume，两边的数据不一致了。 此时，docker再次收到创建该同名的volume时，首先查找缓存发现已经存在这个volume了，于是不再创建直接返回成功。之后docker再收到删除该volume的请求时，docker会调用convoy删除，而convoy中已经没有这个volume了，于是向docker返回失败的信息，因而docker也返回失败。

##解决方案 当我们试图去解决这个问题的时候，发现docker 1.11版本已经解决这个问题： bug：https://github.com/docker/docker/issues/21403 patch：https://github.com/docker/docker/commit/f04334ea040500181727c47dc626171e98660cae 解决方法： 在list volume的时候，如果缓存中不存在这个volume，不再继续添加到缓存中，这样就能避免docker中的数据比convoy中的数据多。 虽然还是会有数据不一致的问题，但只要docker的数据比plugin的数据少，那么每次请求时docker就会再次去请求plugin，这种不一致没有问题。 相反，如果docker中有某个volume的数据，而convoy中却没有该数据，那么就会产生问题。上图中添加缓存的那几行代码正是导致了docker的数据比convoy的数据多，问题就产生了。

相信，现在这个阶段，大家都在使用的docker版本都比1.10大了。否则，要打上这个patch。