On 06/08/09 02:52, Jia Ju Zhang wrote:
Just RFC:
I noticed that 'vgchange -ay' can convert the lock which locked by 'vgchange -aey'
from EX to CR. Is that acceptable to change the logic into always allocating a new lock
rather than converting an existing lock?
In that case, 'vgchange -ay' won't change the result of 'vgchange -aey'. But if we really
want to convert the lock, we can firstly invoke 'vgchange -aen' to release the EX lock,
then invoke the 'vgchange -ay'.
Does this make sense? Or what side effect it may introduce?
I think it makes no sense at all, and have already said so on this list.
As far as I know there is no bugzilla for this problem and therefore it
isn't being worked on.
So ... if you care about this ... you know what to do ;-)
Chrissie
On 8/6/2009 at 9:39 AM, in message<4A7A346B.A94 : 39 : 18251>, Jia Ju Zhang
wrote:
On Fri, 2009-07-31 at 21:29 +0200, brem belguebli wrote:
Hi,
Same behaviour as the one from Rafael.
Everything is coherent as long as you use the exclusive flag from the
rogue node, the locking does the job. Deactivating an already opened
VG (mounted lvol) is not possible either. How could this behave in
case one used raw devices instead of FS ?
But when you come to ignore the exclusive flag on the rogue node
(vgchange -a y vgXX) the locking is completely bypassed. It's
definitely here that the watchdog has to be (within the tools
lvchange, vgchange, or at dlm level).
Is there an open bugzilla # for this? Would like to follow this issue.
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
