Hi,
The reason is found out, as you've predicted.
> is it because of slow read operation (i.e. some raid arrays are known to
> wake-up slowly)
The udev worker is blocked until timeout before killed, cause the
"blkid" in /usr/lib/udev/rules.d/13-dm-disk.rules is too slow because
of high IO load o
Hi,
> Although the /dev/dm-26 is visible, but the device seems not ready in kernel.
Sorry, it's not:
[root@iZuf6dbyd7ede51sykedamZ ~]# dmsetup info /dev/dm-26
Device dm-26 not found
Command failed.
[root@iZuf6dbyd7ede51sykedamZ ~]# dmsetup info /dev/dm-25
Name: vg0-21
State:
Hi,
> Since the /dev/dm-x has been created, I don't understand what it waits
> udev to do?
> Just waits udev rules to create device symbol links?
Although the /dev/dm-26 is visible, but the device seems not ready in kernel.
[root@iZuf6dbyd7ede51sykedamZ ~]# dmsetup udevcookies
Cookie Semid
Hi!
> When udev kills its worker due to timeout - so udev rules was not finished
> within predefined timeout (which unfortunately changes according to mind
> change of udev developer - so it ranges from 90seconds to 300seconds depending
> on date of release) - you need to look out for reason why t
Dne 12. 04. 19 v 10:58 Eric Ren napsal(a):
Hi,
As subject, it seems a interaction problem between lvm and systemd-udev:
```
#lvm version
LVM version: 2.02.130(2)-RHEL7 (2015-10-14)
Library version: 1.02.107-RHEL7 (2015-10-14)
Driver version: 4.35.0
```
lvm call trace when hangs:
Hi,
As subject, it seems a interaction problem between lvm and systemd-udev:
```
#lvm version
LVM version: 2.02.130(2)-RHEL7 (2015-10-14)
Library version: 1.02.107-RHEL7 (2015-10-14)
Driver version: 4.35.0
```
lvm call trace when hangs:
```
(gdb) bt
#0 0x7f7030b876a7 in semop ()
