Luca Berra wrote:
the above is called FUD
No, it is called extensible design. I didn't make claims that the sky is falling or any other such nonsense, I simply pointed out what new requirements may be added in the future, and that if it isn't too hard, we should design the system now to be able to handle those new requirements.
udev is not the only thing on earth that wants to activate a volume group. what if i wanted to do it manually?
Then you do so manually. This discussion is about what the system does automatically.
whoever wrote about editing the conf file? i wrote about detecting that a device is already in user by device-mapper and skipping that.
Johnathan Brassow suggested adding the devices claimed by dmraid to lvm's filter spec in its conf file.
What I am saying is to generalize your suggestion. Rather than specifically code the lvm tools to use the dm ioctls to check if a device is in use and avoid using it, take a more general approach that will work on similar problems as well, that don't involve device mapper targeting the underlying device, and may be easier to implement.
If udev uses pvscan on each disk to find out if it is a member of a vg, it can then note which vg it is a member of in its db. Then it can invoke lvm to attempt to activate that vg, explicitly telling lvm which devices comprise the known pvs of that vg ( since it knows this information ), rather than letting lvm scan /dev/sd*. When dmraid activates a raid set, udev can note that the physical disk is claimed by dmraid, and it will never ask lvm to do anything with it.
Not only does that solve the lvm/dmraid problem, but any future reasons that arise for lvm NOT to scan a given volume can be solved using the same udev attributes rather than having to patch lvm ( and dmraid ).
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
