How are you performing the failures? It looks like just one machine
is loosing its connection to the device, while the other machines
links remain in place.
brassow
On Feb 17, 2008, at 6:49 AM, Lajkó Attila wrote:
Here is the output of vgreduce:
ftp://ftp.ulx.hu/upload/clvmd/vgreduce.tar.gz
Attila
2008. febr. 15, 22:06 DU dátummal Jonathan Brassow <jbrassow@redhat.com
>
ezt írta:
If the problem is reproducible, we should be able to track it down.
When a failure happens, the kernel sends an event to userspace that
signals 'dmeventd' to take action. If we take dmeventd out of the
picture, we can run the commands ourselves with higher verbose
settings.
When you activate the volume, you can 'lvchange -ay --monitor n <vg>/
<lv>' - this will prevent dmeventd from monitoring the mirror. Then
kill the log device. Finally, run 'vgreduce --removemissing <VG> -
vvvv' to perform the recovery. (redirecting all the output to a file
will give us something to look at if the failure is reproduced.)
We may need to grab debugging output from clvmd too, but that can get
messy, so we'll start with this.
brassow
P.S. It looks like you must have *.debug; in your /etc/syslog.conf,
yes?
On Feb 15, 2008, at 10:17 AM, Lajkó Attila wrote:
_______________________________________________
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/
_______________________________________________
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/
