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 <[email protected]>: > > 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 >> [email protected] >> https://www.redhat.com/mailman/listinfo/linux-cluster >> > > -- > Linux-cluster mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/linux-cluster >
-- Linux-cluster mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-cluster
