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@xxxxxxxxxx
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
