lvmetad activation problem with MD devices

lvmetad activation problem with MD devices

[Alexander Tsoy]

Hello.

Commit 8d1d83504dcf9c86ad42d34d3bd0b201d7bab8f6 introduced the
following problem. If MD device is assembled in initramfs and some LVs
on it are not activated, then those LVs still not activated during
system boot.

This, for example, breaks setups where initramfs is generated with
dracut and LVs selectively activated using "rd.lvm.lv" kernel cmdline
option.

-- 
Alexander Tsoy

lvmetad activation problem with MD devices

[Alexander Tsoy]

? Mon, 30 Sep 2013 20:36:15 +0400
Alexander Tsoy <alexander@tsoy.me> ?????:

> Hello.
> 
> Commit 8d1d83504dcf9c86ad42d34d3bd0b201d7bab8f6 introduced the
> following problem. If MD device is assembled in initramfs and some LVs
> on it are not activated, then those LVs still not activated during
> system boot.
> 
> This, for example, breaks setups where initramfs is generated with
> dracut and LVs selectively activated using "rd.lvm.lv" kernel cmdline
> option.
> 

Just an example.

Setup:
md0 -> vg00 -> { lv00, lv01, lv02, lv03 }
md1 -> vg01 -> { lv04, lv05 }

Dracut options passed to the kernel cmdline:
rd.md.uuid=<UUID_of_md0> rd.lvm.lv=vg00/lv00 rd.lvm.lv=vg00/lv01

What happens in initramfs:
- md0 is assembled
- vg00/lv00 and vg00/lv01 are activated

What happens during system boot:
- md1 is assembled
- vg01/lv04 and vg01/lv05 are activated


vg00/lv02 and vg00/lv03 are not activated.

-- 
Alexander Tsoy

lvmetad activation problem with MD devices

[Peter Rajnoha]

On 09/30/2013 06:36 PM, Alexander Tsoy wrote:
> Hello.
> 
> Commit 8d1d83504dcf9c86ad42d34d3bd0b201d7bab8f6 introduced the
> following problem. If MD device is assembled in initramfs and some LVs
> on it are not activated, then those LVs still not activated during
> system boot.
> 
> This, for example, breaks setups where initramfs is generated with
> dracut and LVs selectively activated using "rd.lvm.lv" kernel cmdline
> option.
> 

Yes, sorry for the problem. I'm just working on a fix. The source of
the problem here is that udev database is not handed over from initramfs
for MD devices and so the udev state is simply lost. The state information
we need is the MD activation state.

Thing here is that MD is activated in a very similar way like device-mapper devices
are - ADD event (where the MD device is not yet usable, but only added to the system)
followed by the actual MD activation and the accompanying CHANGE event.
Though CHANGE events are also generated for any WATCH udev rule, which means it's
generated every time the dev is closed after being open for read-write (or it may
be any other spurious CHANGE event generated by just doing echo change > /sys/block/<device>/uevent).

Now, if we reacted to those CHANGE events, we'd end up activating any LVM
stack on top on every CHANGE event - that's wrong (we had bug reports for this).
That's unacceptable. We need to restrict it to activation only on CHANGE event
that comes after the real activation of the MD device underneath. We've solved that
with that patch you mentioned above, however, we need the udev database state
to be properly handed over from initramfs for this to work completely. And udev
seems to save time here a bit by keeping this state from initramfs only for selected
devices - device-mapper devices are included as we requested it long time ago,
but MD is not there yet.

I'll try to negotiate with udev team to include MD devices too (as well as any
other devices that are activated only after a CHANGE event, not ADD event as
otherwise it makes making udev rules almost impossible if we want to differentiate
the real CHANGE event coming from the device activation and CHANGE event coming
from the WATCH rule - when the activation is event based, this could cause
confusion for any activation code.

Another important thing that comes into play and makes this a little bit harder
is the coldplug that is done at boot. At this time, ADD events are generated
artificially so the udev processing is reentered for all existing devices in
the system and udev database updated accordingly. This is also the time when
all the rest of the devices not activated in the initramfs get their chance
to get activated properly.

Another thing to take into account is that the udev rule set used in the
initramfs is not an exact copy of what's installed in the system. So if we're
handing over the udev database state from initramfs (and adding any new device
to the list of devices for which the udev database should be copied from initramfs)
require the audit of the udev rule set and we need to be sure it's compatible
with what system udev rules are.

So we need to count with all of these for a proper solution...
I'll keep you informed about a fix.

Peter

lvmetad activation problem with MD devices

[Peter Rajnoha]

On 10/01/2013 09:05 AM, Peter Rajnoha wrote:
> On 09/30/2013 06:36 PM, Alexander Tsoy wrote:
>> Commit 8d1d83504dcf9c86ad42d34d3bd0b201d7bab8f6 introduced the
>> following problem. If MD device is assembled in initramfs and some LVs
>> on it are not activated, then those LVs still not activated during
>> system boot.
> 
> Yes, sorry for the problem. I'm just working on a fix. The source of
> the problem here is that udev database is not handed over from initramfs
> for MD devices and so the udev state is simply lost. The state information
> we need is the MD activation state.

There's also a bug reported for this issue:

  https://bugzilla.redhat.com/show_bug.cgi?id=1011704

I've handed that over to dracut as we can solve this by adding a special
'OPTIONS+="db_persist"' udev rule to MD rules that are installed for MD
devices in initramfs. This is already done for device-mapper devices in
dracut.

The proposed patch is simple (also tested on my system where I reproduced
the original problem):

  https://bugzilla.redhat.com/attachment.cgi?id=805841

Peter

lvmetad activation problem with MD devices

[Alexander Tsoy]

? Tue, 01 Oct 2013 13:24:59 +0200
Peter Rajnoha <prajnoha@redhat.com> ?????:

> On 10/01/2013 09:05 AM, Peter Rajnoha wrote:
> > On 09/30/2013 06:36 PM, Alexander Tsoy wrote:
> >> Commit 8d1d83504dcf9c86ad42d34d3bd0b201d7bab8f6 introduced the
> >> following problem. If MD device is assembled in initramfs and some LVs
> >> on it are not activated, then those LVs still not activated during
> >> system boot.
> > 
> > Yes, sorry for the problem. I'm just working on a fix. The source of
> > the problem here is that udev database is not handed over from initramfs
> > for MD devices and so the udev state is simply lost. The state information
> > we need is the MD activation state.
> 
> There's also a bug reported for this issue:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1011704
> 
> I've handed that over to dracut as we can solve this by adding a special
> 'OPTIONS+="db_persist"' udev rule to MD rules that are installed for MD
> devices in initramfs. This is already done for device-mapper devices in
> dracut.
> 
> The proposed patch is simple (also tested on my system where I reproduced
> the original problem):
> 
>   https://bugzilla.redhat.com/attachment.cgi?id=805841
> 
> Peter

Yeah, this looks like a proper fix.

Thanks for the detailed explanation.

-- 
Alexander Tsoy