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.
next prev parent 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).