[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: A quite tricky LVM issue



Hi,

On 04/06/2010 04:58 PM, 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 :/


The problem is not as much wether we use the cmdline or a config file, but
that we dynamically build the list of ignored devices as we scan them
(checking if a disk is not in exclusive disks as the disk is scanned), but
lvm does its own scanning, and when we've not yet scanned a disk, it is
not in our to be ignored list yet. Which is why I was thinking towards
a 2 pass scan, but what Dave suggests in the other mail would be better,
we really don't want lvm to go and probe all disks anyways, but only
those we are interested in. See my reply to Dave's mail.

Regards,

Hans



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]