[Cluster-devel] [GFS2 PATCH 1/2] GFS2: Introduce EXSH (exclusively shared on one node)

[Steven Whitehouse]

Hi,


On 18/04/18 20:32, Bob Peterson wrote:
> ----- Original Message -----
>> Hi,
>>
>>
>> On 18/04/18 17:58, Bob Peterson wrote:
>>> This patch is a first step in rgrp sharing. It allows for a new
>>> type of glock mode called EXSH, which stands for a lock that is
>>> Exclusive to one node, but shared amongst processes on that node.
>>> Like a Shared glock, multiple processes may acquire the lock in
>>> EXSH mode at the same time, provided they're all on the same
>>> node. All other nodes will see this as an EX lock. In other words,
>>> to the DLM, the lock is granted to the node in EX, but at the
>>> glock layer, they may be shared.
>>>
>>> For now, there are no users of the new EXSH glock mode.
>>> Future patches will use it to improve performance with rgrp sharing.
>> Is there a reason why we cannot just add a lock flag here, rather than
>> requiring a new lock state? That should make it a much smaller change,
>> and leaves the lock state always reflecting the cluster lock state,
>>
>> Steve.
> Hi,
>
> Well, yes, we can add a new lock flag. The new locking mode just
> gave me more clarity how I thought about things. A flag ought to
> work just as well.
>
> I was also trying to extrapolate how we can use this in the future
> for other types of local lock sharing, but we can also do that
> with the same flag.
>
> Also, I had originally coded it so it did everything through glops,
> but I decided it was just too confusing to follow.
>
> Regards,
>
> Bob Peterson
> Red Hat File Systems

We have four existing lock modes (EX, SH, DF and UN) which means that if 
you add a new one, then we are adding 8 new state transitions (to and 
from the new mode from each existing mode) that need to be tested and 
verified. I think adding a flag to allow local sharing of the EX mode 
would be much simpler since it avoids the need for any additional state 
transitions.

Note that we also have a lock rule that allows local requests for SH 
locks to be granted against an EX DLM lock to avoid the additional DLM 
request when GL_EXACT is not set. This is basically the same thing, but 
with EX glocks on an EX DLM lock, so we might as well use as similar a 
mechanism as we can - again that should simplify things.

I did also spot this in gfs2-glocks.txt which needs updating:

> Also, eventually we hope to make the glock "EX" mode locally shared
> such that any local locking will be done with the i_mutex as required
> rather than via the glock.


Steve.