We already have VG/LV autoactivation with lvmetad + udev. Explore a possibility to do the exact opposite - autodeactivate the VG/LV if underlying PVs get disconnected or unplugged. The existing "blkdeactivate" script may be useful here - attach the blkdeactivate call to REMOVE uevent. The blkdeactivate script will probably need some tweaking to handle missing /sys entry as well as different lsblk output for this situation - on REMOVE uevent the device is already removed from kernel.
Some areas that comes to my mind and which needs exploring and taking into account: - mounted volumes - mirror legs (do not deactivate the LV in this case - dmeventd will handle mirror repair) - replacing the dm table with "error" target to get rid of apps using the dev (there should be IO errors already when the device is unplugged, but is this happening all the time? Are there any timeouts?)
I am a rather naive user of LVM. I don't use mirrors or even LVs that span between PVs. If one attaches an external disk, and the disk contains no LVM PVs, one may safely detach it at any time, provided that none of its partitions have been mounted (and no process is directly accessing any of the partitions). It seems "natural" to me that the same should happen with regard to LVM partitions. As long as none of the LVs are being "used" (mounted or otherwise), it should cause no problem to detach the disk. (I assume that LVM maintains no un-written cached information for LVs that are not in use.) On my system (Fedora 19), it seems that there is some process that quickly detects newly attached disks. In effect, it frequently does "vgscan ; vgchange -ay". It seems natural to me that either the automatic or the manual process should properly detect and remove from the LVM system any LVs which have been disconnected. I'm sure there are situations where these expectations can't be satisfied, but simple situations where these actions appear to be straightforward should work.
(In reply to Dale R. Worley from comment #2) > I'm sure there are situations where these expectations can't be satisfied, > but simple situations where these actions appear to be straightforward > should work. Sure, but first we need to define properly what are all the "simple" situations. Thing is to not do any quick fixes/decisions that would make troubles for other people with more complex setup just because we forgot to rule out some situations for which a more complex solution is needed. IOW, we need to avoid blindly deactivating all the volumes. I've opened this bug exactly for that - to make notes and gather ideas about anything that comes to my mind and which needs to be taken care of. Anyway, I really wouldn't go for F19 here - this is something that needs to be tested well and should first land in rawhide...