From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Rajnoha Date: Tue, 01 Oct 2013 09:05:49 +0200 Subject: lvmetad activation problem with MD devices In-Reply-To: <20130930203615.59bfd346@work.puleglot> References: <20130930203615.59bfd346@work.puleglot> Message-ID: <524A744D.207@redhat.com> List-Id: To: lvm-devel@redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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//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