After some more testing, I have found that the udev rule was running
lvchange -a y whenever a PV is added or changed. It seems that nearly
any lvm command causes a change event to be emitted on the PVs. Why is
this? After I removed the |change clause from the udev rule so that
lvchange is no longer run on these change events, I now see that indeed,
running lvchange -a manually to reactivate an origin volume with a
pending merge does cause it to activate and merge in the background,
during which time it can be mounted. Strangely though, while the merge
is taking place in the background, I still see change events on the
underlying PVs being emitted. Also running lvs while the merge is still
on going reports IO errors trying to read the snapshot volume, which
makes sense since according to dmsetup table, it consists only of the
error target.
With the change to the udev rule, the system boots immediately and
finishes the merge in the background, as it should, leading me to
conclude that the problem was all of the udev event ping-pong causing
udevadm settle to hold up the boot.
On 10/20/2010 05:08 PM, Phillip Susi wrote:
On 10/20/2010 4:55 PM, Mike Snitzer wrote:
"Before finishing the boot"... can you be more specific? Where was it
stopped waiting for a snapshot merge? How did you know it was waiting
for snapshot merge? Which distro are you using?
It seemed to be stopped waiting for the initial activation of the root
lv before continuing with the boot. This manifested as a several minute
delay before the gui came up, and when I checked the bootchart image, it
was indeed sitting running lvm for a long time before everything else.
This is with Ubuntu 10.10.
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
