[lvm-devel] 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