Hi,
> Hmm would it be possible that associated thin pool would be in some erroneous
> condition - i.e. out-of-space - or processing some resize ?
The testing model is:
create/mount/"do IO" (on) thin LV; and then umount/delete thin LV.
doing this work flow in parallel.
> This likely could
wer nichts macht kann auch nichts lernen
- On Apr 11, 2019, at 7:25 PM, Bernd Lentes
bernd.len...@helmholtz-muenchen.de wrote:
> - On Apr 11, 2019, at 5:59 PM, Zdenek Kabelac zkabe...@redhat.com wrote:
>> So here is the reason:
>>
>> ioctl: can't change device type after initial
Dne 12. 04. 19 v 17:03 Eric Ren napsal(a):
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
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:
Dne 12. 04. 19 v 16:56 Eric Ren napsal(a):
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
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
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
Dne 12. 04. 19 v 12:42 Eric Ren napsal(a):
Hi!
Looking at provided log file - the system seems to be using some weird udev
rule - which results in generating strange /dev/__ symlinks.
Yes! I also see these weird device names, but I don't have a good
explanation for it, so that I'm stupid
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:
Dne 11. 04. 19 v 19:33 Eric Ren napsal(a):
Hi Zdenek,
Anyway - proper reproducer with full - log would be really the most
explanatory and needed to move on here.
The activation error is reproduced once more. Please see lvm2.log attached.
Please search the error message like this:
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
11 matches
Mail list logo
