[Linux-cluster] Fwd: CLVM exclusive mode

[brem belguebli]

Hi ,

For those concerned by this  topic,
Redhat made an update that will hopefully be operational.

https://bugzilla.redhat.com/show_bug.cgi?id=517900

Thx

Regards

2009/8/17, brem belguebli <brem.belguebli at gmail.com>:
> done,
>
> Bug 517900
>
>
> 2009/8/17, Pasi Kärkkäinen <pasik at iki.fi>:
> > 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 <hxinwei at gmail.com>:
> > > >
> > > > Hi,
> > > >
> > > > Attached a very naive try to solve the issue you have.
> > > >
> > > > Would you give it a test ?
> > > >
> > > > Thanks.
> > > >
> > > > 2009/8/16 brem belguebli <brem.belguebli at gmail.com>:
> > > > > 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 at redhat.com>:
> > > > >>
> > > > >> 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 at redhat.com
> > > > >>>
> https://www.redhat.com/mailman/listinfo/linux-cluster
> > > > >>
> > > > >> --
> > > > >> Linux-cluster mailing list
> > > > >> Linux-cluster at redhat.com
> > > > >>
> https://www.redhat.com/mailman/listinfo/linux-cluster
> > > > >
> > > > >
> > > > > --
> > > > > Linux-cluster mailing list
> > > > > Linux-cluster at redhat.com
> > > > >
> https://www.redhat.com/mailman/listinfo/linux-cluster
> > > > >
> > > >
> > > > --
> > > > Linux-cluster mailing list
> > > > Linux-cluster at redhat.com
> > > > https://www.redhat.com/mailman/listinfo/linux-cluster
> > > >
> > > >
> >
> > > --
> > > Linux-cluster mailing list
> > > Linux-cluster at redhat.com
> > > https://www.redhat.com/mailman/listinfo/linux-cluster
> >
> > --
> > Linux-cluster mailing list
> > Linux-cluster at redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-cluster
> >
>
>