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@xxxxxxxxx>:
> 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@xxxxxxxxxx>:
>>
>> 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@xxxxxxxxxx
>>> https://www.redhat.com/mailman/listinfo/linux-cluster
>>
>> --
>> Linux-cluster mailing list
>> Linux-cluster@xxxxxxxxxx
>> https://www.redhat.com/mailman/listinfo/linux-cluster
>
>
> --
> Linux-cluster mailing list
> Linux-cluster@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/linux-cluster
>
diff --git a/daemons/clvmd/lvm-functions.c b/daemons/clvmd/lvm-functions.c
index 23d740c..679e4d1 100644
--- a/daemons/clvmd/lvm-functions.c
+++ b/daemons/clvmd/lvm-functions.c
@@ -241,8 +241,9 @@ int hold_lock(char *resource, int mode, int flags)
flags &= LKF_NOQUEUE; /* Only LKF_NOQUEUE is valid here */
- if ((lvi = lookup_info(resource))) {
- /* Already exists - convert it */
+ if ((lvi = lookup_info(resource)) && (lvi->lock_mode != LKM_EXMODE)) {
+ /* XXX: not to convert an exclusive lock */
+ /* Already exists, and not an exclusive one - convert it */
status =
sync_lock(resource, mode, LKF_CONVERT | flags,
&lvi->lock_id);
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
