Re: Re: LVM on dmraid breakage

[Phillip Susi <psusi@cfl.rr.com>]

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 ).