[dm-devel] Why is device mapper unable to remove a mapped devicewhich is open?

[Edward Goggin]

On Friday, September 22, 2006 4:43 PM, Alasdair G Kergon wrote:

> On Fri, Sep 22, 2006 at 04:26:16PM -0400, goggin, edward wrote:
> > Why shouldn't the kernel's reference counting for the
> > mapped device's md structure account for properly 
> > handling the de-allocation of the md structure upon
> > the last close in this case?
> 
> This behaviour has flipped a couple of times during the
> development.
> 
> It would be fine if devices could never be suspended.
> You can't close a suspended device you've written to
> until it gets resumed.  If you've removed it you can't
> resume it because it has gone.
> 
> It's similar in a way to how the kernel used to (at least I 
> assume someone
> fixed it?) let you unlink a swap file and then it was impossible to
> 'swapoff' because you couldn't reference the device any more.

What about having mapped device specific dm ioctls be issued
to (the file descriptor of) the affected mapped device instead
of to the dm control device?  I think this would include
at least such dm ioctls as dev_remove, dev_rename, dev_suspend,
dev_status, dev_wait, table_load, table_clear, table_deps,
table_status, target_message, and dev_set_geometry.  The dm
ioctls such as remove_all, list_devices, dev_create, list_versions,
and version would remain associated with the dm control device.

While this approach would require having both the dm control
device and the actual mapped devices service ioctls and requires
reserving a range of ioctls for exclusive use by dm, the clear
advantage is that name translation for these ioctls would not
be required.