[dm-devel] Re: LVM on dmraid breakage
Phillip Susi
psusi at cfl.rr.com
Mon Aug 6 14:45:02 UTC 2007
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 ).
More information about the Ataraid-list
mailing list