[linux-lvm] lvm_vg_create_lv_linear() stuck in dm_udev_wait()

[Zdenek Kabelac]

Dne 29.8.2011 17:47, Alexander Lyakas napsal(a):
> Hello Zdenek,
> I did some investigations, and I think the problem is the following:
> 
> When an LV is created, udev event comes in. It looks like the problem
> happens only when this first udev event has the following properties:
> ID_FS_UUID=INtL1j-fpvA-Xx13-iXSL-XtDx-ekzV-8aGHg1 (or something else)
> ID_FS_UUID_ENC=INtL1j-fpvA-Xx13-iXSL-XtDx-ekzV-8aGHg1 (or something else)
> ID_FS_VERSION=LVM2\x20001
> ID_FS_TYPE=LVM2_member
> ID_FS_USAGE=raid
> 
> Usually, I see these properties on PVs (which are MD arrays) and not on LVs.
> I don't really know why these properties sometimes appear on a new LV
> (some leftover on disk???), but when it happens, then the following
> ubuntu udev rule kicks in:
> 
> ---------- code ----------
> # This file causes block devices with LVM signatures to be automatically
> # added to their volume group.
> # See udev(8) for syntax
> SUBSYSTEM=="block", ACTION=="add|change",
> ENV{ID_FS_TYPE}=="lvm*|LVM*", RUN+="watershed sh -c '/sbin/lvm vgscan;
> /sbin/lvm vgchange -a y'"
> ------ end code -------
> 
> This rule is described here:
> https://wiki.ubuntu.com/UdevLvm
> 
> So vgscan is issued and it gets stuck waiting for the LVM lock,
> because currently my thread is stuck in lv_create_linear(), waiting
> for udev event, and my thread holds this lock.
> 
> At this point the system is stuck. What I did then, I killed the
> vgscan and vgchange processes, but still additional udev events did
> not come. Then I issued 'udevadm settle' and next udev event arrived.
> This next event did not contain the problematic ID_FS_XXX fields. And
> then LV creation completed smoothly. Also, in all the cases, in which
> LV creation went smoothly, I did not see the ID_FS_XXX fields.
> 
> So I have several doubts:
> 1) I understand why vgscan was stuck, but do not understand why udev
> events stopped coming. Does udev need the previous event processing
> rules to complete, before sending new events?
> 2) Why these problematic ID_FS_XXX properties appeared, and how can we
> prevent this?
> 3) Or otherwise, do you think that ubuntu's rule is problematic? In my
> case, I don't need this rule, because I activate all the LVs in my
> code anyways.

I assume udev vars are being set from blkid execution on block device.

I really think version 2.02.66 is way to obsolete especially if all
surrounding apps (like udev) have been upgraded many times.

Vgscan should not be executed by any udev rules.

lvm2 package is bundled with its own  udev rules - which are tested and
verified to work. If a distribution decides to ignore them and bundle its own
version I afraid you need to ask for help the package maintainer in your
distro for such support.

So I'd suggest to to install latest version from upstream tarball otherwise
you will be losing your time fighting with more then a year old bugs.

Zdenek