<div>done,</div> <div> </div> <div><a title="NEW - bypass of exclusive vg/lv lock" href="https://bugzilla.redhat.com/show_bug.cgi?id=517900">Bug 517900</a> </div> <div>2009/8/17, Pasi Kärkkäinen <<a href="mailto:pasik@iki.fi">pasik@iki.fi</a>>: <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Mon, Aug 17, 2009 at 04:10:01PM +0200, brem belguebli wrote: > Hi, > > Thanks a lot. > > I'll try it, but would be enjoyed if RH could implement it. > Did you already open bugzilla entry about it? Quote from this same thread: "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" -- Pasi > Regards > > > 2009/8/17, Xinwei Hu <<a href="mailto:hxinwei@gmail.com">hxinwei@gmail.com</a>>: > > > > 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> > > > > > -- > 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>