The former lock may be more scalable, but it is not safe.

Assume we create two volume simultaneously with the same name, the lock can not protect the create process.

I think it was pretty safe. And real create command can take some time. Anyway ping @calavera @cpuguy83

@LK4D4 During the real create command which takes a long time, maybe another volume with same name is created. This could happen in very low probability though not completely impossible.

@LK4D4 I agree with @x1022as . I can reproduce this situation use volume plugin convoy which will take a long time to create a volume.
On a terminal type
docker volume create --name test -d convoy
which will take a few seconds to create a volume
At the same time on another terminal
docker volume create --name
which will create local volume immediately.
during the creation type docker volume ls the driver is different.

$ docker volume ls
DRIVER              VOLUME NAME
local               test
$ docker volume ls
DRIVER              VOLUME NAME
convoy              test

I think this PR is need.

LGTM

The issue is that it will block all volume creates due to a slow or down volume driver.

Maybe registering the name and creating the volume should be separate? Will probably need a "state" for the volume ("creating"), and if the actual create fails for some reason, the name can be released

Maybe use per-volume lock instead of a global one to protect these volume operation? Lock with finer granularity will increase scalability.

any updates here?

Closing in favor of #17185

With this, we'll end up with a deadlock when trying to containerize a volume driver.