Comment 5 for bug 585027

In examining the ioctl interface to device mapper (kernel), I have not found any architecture that
assures that when a device mapper device has been marked for deletion, that this information is
relayed back to userspace so it can block on this deletion. An example will clarify things.

In SD we have a state machine the details the teardown of a SCSI device. Deletion is "latched" in
two FSM states, SDEV_CANCEL and SDEV_DEL. The first state tells everyone that this device is
on it's way out and to stop trying to use it, DEL is the final state where callbacks start the
kobj destruction process. In this model, it's easy to determine that a device is being deleted
by examining the state variable in sysfs. It's of little consequence here as SD devices are not
deterministic, the same name need not be used, if sdd was being deleted, and another hotplug
create event was generated, SD would hand you sde. Deterministic names are left to udev.

In the device mapper case, the WWID is a deterministic and unique name, there is no substitute.
Once the device has been marked for deletion, there's no readily apparent way to verify that it has in
fact been marked for deletion. dev_status is the closest we can get, and the flags it provides
are not clear enough to determine that a device is being deleted. Therefore, the mechanism
does not exist to even poll for the destruction of a dm name, as we can't even determine that
the dm name is being destroyed. We couldn't wait for deletion if we wanted to.

http://lxr.linux.no/linux+v3.4.4/drivers/md/dm-ioctl.c#L656

So this really isn't a bug, it's an example of DM's current design. If we want to address the issue
then we'll have to propose an enhanced tear down protocol, and then update any device mapper
consumers to use this protocol. There might be a way to infer a deletion state from a combination
of flags, but that will take a concentrated effort to determine. This issue is a synthetic fault at best,
there's no real impact to the user.