[dm-devel] Re: LVM on dmraid breakage
Luca Berra
bluca at comedia.it
Sat Aug 4 06:50:48 UTC 2007
On Fri, Aug 03, 2007 at 05:30:00PM -0400, Phillip Susi wrote:
>Luca Berra wrote:
>>On Fri, Aug 03, 2007 at 02:10:02PM -0400, Phillip Susi wrote:
>>>I agree with moving the partition detection code to user space, but
>>>trying to undo it after the fact doesn't help because udev is already
>>>processing the add events. Also you do not need to remove the
>>>partitions so long as pvscan understands that it shouldn't be using them.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>which is the modification i proposed to lvm tools, isn't it?
>
>You suggested deleting the partition table after it has already been
>detected. I am saying that while I agree in principal that partition
I was referring to the modification to lvm2, not the one to dmraid.
>detection should be moved out of the kernel, for now, it is in there and
>deleting them after they have already been detected doesn't help matters
>because pvscan may already be running on them.
Actually i am not worried too much about vgscan/pvscan, i am much more
worried for mount, swapon, one particular piece of crap called
hibernate-cleanup.sh etc.
besides, i am positive that users get confused having both /dev/sda1 and
/dev/mapper/via_aggehhahyue1
>>>Udev is supposed to be the new model for enumerating devices and
>>i know that, and i will withdraw from this discussion, since it might
>>get to an useless flame war.
>>
>>Is there any technical reason for not having lvm tools filter out
>>devices that
>>are used by device mapper?
>>
>>besides dmraid, think of multipath.
>
>None that I can see at the moment, but that doesn't mean there isn't
>one, or won't be one in the future. The other problem is that there are
the above is called FUD
>likely other factors besides being used already as a dm target that
>might give reason for lvm to not scan the volume. These kind of policy
probably, we strive to be perfect, but we still have a long way to
go...
>decisions seem like they should be made by udev rather than hard coded
>into lvm. If the admin wants a policy where lvm should look at volumes,
>or indeed, maybe only certain volumes, that already happen to be dm
>targets, he should be able to do that. Likewise, there may be some
udev is not the only thing on earth that wants to activate a volume
group. what if i wanted to do it manually?
>other reason to not look at a disk for lvm pvs. Editing a conf file to
>specify a filter list of devices by name is all well and good for a
>static system, but it does not play well in the modern udev managed plug
>and play world.
whoever wrote about editing the conf file?
i wrote about detecting that a device is already in user by
device-mapper and skipping that.
--
Luca Berra -- bluca at comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
More information about the Ataraid-list
mailing list