Hi, Thanks a lot.
I'll try it, but would be enjoyed if RH could implement it. Regards 2009/8/17, Xinwei Hu <[email protected]>: > > Hi, > > Attached a very naive try to solve the issue you have. > > Would you give it a test ? > > Thanks. > > 2009/8/16 brem belguebli <[email protected]>: > > 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 > > > > -- > 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
