On 01/20/2014 12:49 PM, Peter Rajnoha wrote: > On 01/17/2014 11:02 AM, Marius Vollmer wrote: >> [ I am not subscribed, so please keep me in CC. I'll just reply to >> myself, sorry for breaking the threading. >> ] >> >> Peter Rajnoha wrote: >> >>> For now, these flags are only documented directly in libdevmapper.h >>> (as they were only meant to direct udev rules and these situations >>> were all audited directly by communicating with other teams). I could >>> probably add a few lines to the man page directly though as others >>> could use this even when reading udev database... >> >> That would be great! >> >>> However, for your purpose, I'd better use >>> DM_UDEV_DISABLE_OTHER_RULES_FLAG which just tells that everything else >>> other than DM/LVM related should skip this device. >> >> Hmm, DM_UDEV_DISABLE_OTHER_RULES_FLAG is (now) set for thin volumes, as >> far as I can tell. This is what lead me down this rabbit hole in the >> first place: UDisks2 _does_ ignore events for nodes with >> DM_UDEV_DISABLE_OTHER_RULES_FLAG set, and since Fedora 20, this causes >> it to ignore thin volumes. >> >> The use of DM_UDEV_DISABLE_OTHER_RULES_FLAG or any other such flag in >> UDisks2 looked like a ugly hack to me, so I started looking for >> alternatives. >> >> The best option seemed to be to ignore any DISABLE flag in UDisks, and >> to set UDISKS_IGNORE for LVM2 block devices that do not have the >> /dev/VG/LV symlink. >> >> Now you say that DM_UDEV_DISABLE_OTHER_RULES_FLAG is actually the Right >> Way, but it seems to be buggy re thin volumes. Correct? >> > > Thing here is that when LVs are created then at first they have this flag > set until proper initialization is finished - meaning zeroing of any existing > signatures found on the volume before this LV can be used cleanly (otherwise, > it could happen that some scanning done outside LVM could find stale metadata > on just created LV, like FS labels, MD signatures.. whatever that might pose > a confusion about what is layed on top of the LV). Only after the signature > wiping is done, the flag is dropped and so others are free to use it as the > LV is clean now. > > However, you're right that in case of thin LVs, this is set incorrectly. > The DM_UDEV_DISABLE_OTHER_RULES flag should not be there. I've fixed that: ...the flag would be gone if you opened the LV for read-write and then close it - you don't even need to write anything to the LV, just open and close - this would fire an event that would have dropped the flag. It was (incorrectly) supposed to be the LVM itself that would open the new thin LV for signature wiping - that would be exactly the "open for RW"/"close" sequence that would have dropped the flag. Though in this exact case the wiping is not done - the thin LV is an exception here and the code handled this incorrectly... -- Peter _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
