[Linux-cluster] Fwd: CLVM exclusive mode

[brem belguebli]

Hi,

Thanks a lot.

I'll try it, but would be enjoyed if RH could implement it.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20090817/e5359846/attachment.htm>