From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Thu, 19 Apr 2018 09:29:38 +0100 Subject: [Cluster-devel] [GFS2 PATCH 1/2] GFS2: Introduce EXSH (exclusively shared on one node) In-Reply-To: <540748805.20967425.1524079955994.JavaMail.zimbra@redhat.com> References: <20180418165838.8342-1-rpeterso@redhat.com> <20180418165838.8342-2-rpeterso@redhat.com> <540748805.20967425.1524079955994.JavaMail.zimbra@redhat.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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.