Hi,
On 04/06/2010 08:16 PM, David Lehman wrote:
On Tue, 2010-04-06 at 19:25 +0200, Hans de Goede wrote:
Hi,
On 04/06/2010 06:29 PM, David Lehman wrote:
On Tue, 2010-04-06 at 10:58 -0400, Peter Jones wrote:
On 04/06/2010 06:06 AM, Hans de Goede wrote:
Hi,
On 04/06/2010 11:54 AM, Ales Kozumplik wrote:
On 03/30/2010 02:30 PM, Hans de Goede wrote:
Hi All,
While doing what should be testing a simple iscsi related patch,
I encountered the following issue:
Take a system with a single disk, sda, which has a /boot on
sda1 and a PV on sda2. This PV is the PV for the 1 PV VG:
VolGroup, which contains LV's lv_swap, lv_root and lv_home.
"Attach" an iscsi disk to this system, which becomes sdb,
which has a /boot on sdb1 and a PV on sdb2. This PV is the PV
for the 1 PV VG: VolGroup, which contains LV's lv_swap and
lv_root.
Notice that:
1) The 2 VG's have the same name
2) Only sda has a lv_home LV.
Now in the filter UI select only disk sdb to install to, then
the following may (depending on scanning order) happen:
Assume sdb gets scanned first by devicetree.py:
- when scanning sdb2, handleUdevLVMPVFormat() will
call "lvm lvchange -ay" for all LV's in this VG
(as seen by udev, more on that later).
- at this point, sda has not been scanned yet, so
isIgnored has not been called for sda2 yet, and thus
lvm_cc_addFilterRejectRegexp("sda2") has not been called
yet.
- thus lvm lvchange sees both sda2 and sdb2, it complains
that there are 2 identically named VG's and picks the one
using the sda2 PV.
Maybe we should stop the installation at this point and tell the user
that he named two VGs the same and needs to address this before
proceeding with the installation? Because otherwise we will need to do
too many changes for a corner case that only occurs infrequently. And we
still won't be completely happy with them.
That won't work, as there actually are no duplicate VG's when looking only
at the devices the user selected in the filter UI, the problem is
that lvm at this point does not honor what we've selected in the filter UI
and what not. Which is caused by the way we build the ignore these devices
cmdline argument for lvm.
Perhaps we should be generating an lvm.conf with a proper filter section for
this instead? It's not really an ideal solution :/
It might be worth passing lvm a full list of the devices it is allowed
to look at instead of telling it which devices to ignore.
I've been thinking in that direction too, and I like it, but ...
We will know
the full list of PVs at activation time.
Do we? Currently we activate LV's from handleUdevLVMPVFormat()
when we find the first PV.
Right, but lv.setup calls vg.setup, which raises an exception if
len(self.parents)< self.pvCount, so that's taken care of.
Ah, well that is hidden pretty well, but ack it is taken care of
then :)
But if you've ideas to change this, I'm all ears. We could delay
bringing up the LV's until the VG actually has pv_count parents,
but this still won't save us from duplicate VG name issues.
Hmm, but if we were to use the VG's UUID as name in the device
tree then this could work. This would probably require quite a bit
of reworking of the code though, as I think there are assumptions
that devicetree name == VG name in quite a few places.
I'm not even sure what we do right now if we encounter two VGs with the
same name. I do see that we try to look up the VG by name in
handleUdevLVMPVFormat. I think it would only help to do all lookups on
existing VGs by UUID instead of name, at least while populating the
tree.
That sounds like a solution, but what to do then when we encounter
a PV of a VG which has the same name but a different UUID then a VG already
in the list ...
Currently we have code to handle corner cases like this, but that does not
run until populating is done.
Note that this problem is less obscure then it seems, it can
be triggered by this PITA called software RAID. If we have a PV on
a software RAID mirror, then lvm will see the PV 3 times, and semi randomly
(or so it seems) pick one (*). So we really must make sure
we've scanned all possible lower level devices before activating
LV's. I've been thinking about this, and a patch for this should not
be all that invasive.
Have you seen this happen, or are you speculating? It seems to me we
would have hit this long ago if it were so simple to set up. I suppose
it's possible that we have and just don't know it.
Normally it does not happen, as the first round through the loop in populate
we scan all the raid set members (and ignore any PV formatting found on
partitions of them as we ignore the partitions), and then only the next round
the set itself gets scanned. But I've seen this happen in the
conflicting VG names case (where I had, 1 sw bios raid mirror, 2 plain disks, and
1 iscsi disk, and the sw bios raid mirror had a 1 pv vg, and the iscsi disk had
a 1 pv vg, and they were named identical).
I think that we've got most normal cases covered already, but we still
have problems with filter ui + conflicting VG names. I think that looking
for existing VG's bij UUID in handleUdevLVMPVFormat() + some sort
of handling in case of Name conflicts + passing which PV's to use
explicitly when activating things might do the trick.
Anyways this needs some more thinking / investigation. So I'm going to
sleep a night on it (time to call it a day for today).
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
