On 07/25/2015 09:34 PM, Bastian Blank wrote:
> Hi Peter
>
> Currently I think that all this problems are related to missing or
> broken pvscan --cache calls.
>
> I found one problematic case regarding coldplug; I believe Redhat does
> not longer use this code path. In none of my tests the "artificial" add
> event triggers pvscan as it should. The udev rules test for
> LVM_MD_PV_ACTIVATED, which is never set in this case.
The MD here is very similar to DM in a way it is activated -
the MD device is created first (the ADD event) and then initialized
(the CHANGE event).
So we're expecting the CHANGE event with appearing md/array_state sysfs
attribute to declare the MD as initialized (and hence marked with
LVM_MD_PV_ACTIVATED=1).
When this MD activation/initialization happens in initramfs, the udev
database state needs to be transfered over from initramfs to root fs for
the MD device.
We're always doing IMPORT{db} for the LVM_MD_PV_ACTIVATED variable
so the rules can check whether the MD device is ready to use or not.
When switching to root fs and when the coldplug is done, the
ADD event is generated for the MD device - when we have ADD event
and at the same time we have LVM_MD_PV_ACTIVATED=1, we know this is
artificial event (the "coldplug" one) and we do jump to the pvscan
in that case.
That's how it was supposed to work. I can imagine the problematic
part here may be the transfer of the udev database state from initramfs
to root fs - there is a special way that udev uses to mark devices
so that the udev db state is kept from initramfs - I need to recall
that/check that because I don't remember that method right now...
--
Peter
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
