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 resul
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 tabl
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 /dev/
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 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 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 to
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!
> 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 to think deep into it.
Thanks!!!
> There are
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:
$grep
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 ()
12 matches
Mail list logo