On 06.07.2013 19:40, matthew patton wrote:
(either hard-coded or using tags) is *necessary* to make things working or if it
is just *adviseable* to prevent using a volume simultaneously from both clients?
You could probably make a case for saying it's adviseable but why do you want to play roulette with your data? Force it to do the right thing and you won't have to run the risk of it doing something unintended. Why the trepidation to doing it correctly?
I just try to understand how things work. But you indeed convinced me to
use tags.
logical values are found by vgscan / lvscan, but I cannot access it. Is this the
expected behavior? Is there any chance (besides rebooting the client machine) to
recover from such a situation?
How did you disconnect from iSCSI? Did you gracefully log out of the client session? However you did it, it seems the kernel believes the device was just yanked offline and after repeated I/O failures marked it bad. Re-introducing the device doesn't magically clear the error state. Then again maybe it's as simple as you not bringing it fully online with a 'vgchange -ay <vg>' and an 'lvchange -ay <lv>'.
After some further investigation I think I have found the reason for the
observed behavior: When I log out of the client session, the block
device (/dev/sda in my case) still seems to be used, probably by the
device mapper itself. So when I log in again, the iSCSI device gets
another device node (/dev/sdb) which obviously doesn't help for the
logical volume. When I deactivate and reactivate the LV, it gets
connected to the new block device and works again.
It also works if I deactivate the LV before logging out of the iSCSI
session. Then the block device is released and reused when I reconnect.
In any case, it seems to be necessary to deactivate and reactivate the LV.
Regards,
Christian
--
Deriva GmbH Tel.: +49 551 489500-42
Financial IT and Consulting Fax: +49 551 489500-91
Hans-Böckler-Straße 2 http://www.deriva.de
D-37079 Göttingen
Amtsgericht Göttingen | HRB 3240
Geschäftsführer: Dirk Baule, Christian Schröder
Deriva CA Certificate: http://www.deriva.de/deriva-ca.cer
_______________________________________________
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/
