<div>Hi,</div> <div> </div> <div>Thanks a lot.</div> <div> </div> <div>I'll try it, but would be enjoyed if RH could implement it.</div> <div> </div> <div>Regards </div> <div>2009/8/17, Xinwei Hu <<a href="mailto:hxinwei@gmail.com">hxinwei@gmail.com</a>>: <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi, Attached a very naive try to solve the issue you have. Would you give it a test ? Thanks. 2009/8/16 brem belguebli <<a href="mailto:brem.belguebli@gmail.com">brem.belguebli@gmail.com</a>>: > 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 <<a href="mailto:ccaulfie@redhat.com">ccaulfie@redhat.com</a>>: >> >> 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 >>> <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> >>> <a href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</a> >> >> -- >> Linux-cluster mailing list >> <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> >> <a href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</a> > > > -- > Linux-cluster mailing list > <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> > <a href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</a> > -- Linux-cluster mailing list <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</a> </blockquote></div>