cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH 1/2] GFS2: Introduce EXSH (exclusively shared on one node)
Date: Thu, 19 Apr 2018 09:29:38 +0100	[thread overview]
Message-ID: <b80ca70d-5d7b-19e3-e233-f0846b9cdff3@redhat.com> (raw)
In-Reply-To: <540748805.20967425.1524079955994.JavaMail.zimbra@redhat.com>

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.



  reply	other threads:[~2018-04-19  8:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-18 16:58 [Cluster-devel] [GFS2 PATCH v1 0/2] Improve throughput through rgrp sharing Bob Peterson
2018-04-18 16:58 ` [Cluster-devel] [GFS2 PATCH 1/2] GFS2: Introduce EXSH (exclusively shared on one node) Bob Peterson
2018-04-18 19:13   ` Steven Whitehouse
2018-04-18 19:32     ` Bob Peterson
2018-04-19  8:29       ` Steven Whitehouse [this message]
2018-04-18 16:58 ` [Cluster-devel] [GFS2 PATCH 2/2] GFS2: Take advantage of new EXSH glock mode for rgrps Bob Peterson
2018-04-18 19:25   ` Steven Whitehouse
2018-04-18 19:39     ` Bob Peterson
2018-04-19  8:43       ` Steven Whitehouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b80ca70d-5d7b-19e3-e233-f0846b9cdff3@redhat.com \
    --to=swhiteho@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).