Fixes issue #13129

@rhatdan will this do?

I thought the last time we all talked we said an external tool would be better for this as you still have to be on the same machine and having something like an API call is a little weird for docker.

ya maybe this could be part of dist tool? idk

@crosbymichael

I was not part of such conversation so I don't have the background. Can you give some more details.
I think Dan once mentioned that there was a proposal to put graph drivers into a library. Is it something along those lines?

How would an external tool know about images and graphdriver managing those images etc.

it does not have to manage anything really, what you are trying to do here is out of band, mount some image into a directory to poke around. You could just have a simple binary that queries the docker API for images and then imports whatever code it needs to mount an image into a directory.

I really don't see the docker API as a good place for commands like this.

@crosbymichael

All the locking is central in docker daemon right now. If I mount an image and somebody is trying to
delete that image, things will be in conflict. Ideally, I should detect that image is already mount and any deletion attempt should fail right there. I am sure there will be many more conflicts like this. May be some sort of file based locking is answer here but that would require a fundamental change in how docker does locking at various levels.

To mount image first we map image name to respective ID. That means I need to copy all the code from docker. Then I use graphdriver to actuall Get() the image. That means ideally I need whole of the graph driver code copied too.

Can't a user first mount the image and then bind volume mount into another container to be able to access it remotely.

• docker mount foo-image foo-dir
• docker run -v foo-dir:/mnt/ -ti fedora bash

@crosbymichael

So say, I get information from docker about pool, image id, associated device id and size from "docker info" and "docker inspect" command and I write a script to use "dmsetup" command to activate that device from thin pool and mount it. I think that should work.

One issue which comes to mind is that docker does not know about this. Now say a docker client says, remove the image, then docker will try and fail halfway when it tries to deactivate the device. That device is mounted somehwere else, hence is busy and hence docker can't delete the image.

It would have been nice if docker could keep an internal map where it knows that user has requested
an image to be mounted and it has not been unmounted yet. So any attempt to delete the image will fail much early with appropriate error message.

So some simple external tools can be written for this but they are not going to integrate well with docker in current form.

This works for me as long as we can handle the locking situation properly.

@crosbymichael

I have created another pull request which exports more metadata about image using "docker inspect" command. Now external tools can use this to activate a thin device and mount image and inspect it.

PR number is #13198

I'm with @jfrazelle and @crosbymichael, I don't think this belongs in the daemon. Sorry, I'm closing this, and taking a look to the new one that you linked.