Hi,
I don't think adding more security can be considered as pointless, especially when this has no impact on performance or behaviour.
The question is, what's the point in allowing the clustered active exclusive lock to be bypassed ?
In comparison to other volume management solutions (on various unices) where these barriers are already implemented, the lack of them on Linux can be seen as a weakness.
Regards
2009/8/6, Christine Caulfield <ccaulfie@xxxxxxxxxx>:
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
wrote:On 8/6/2009 at 9:39 AM, in message<4A7A346B.A94 : 39 : 18251>, Jia Ju Zhang
On Fri, 2009-07-31 at 21:29 +0200, brem belguebli wrote:
Hi,Is there an open bugzilla # for this? Would like to follow this issue.
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).
--
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
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
