From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Mon, 13 Jul 2015 12:19:02 +0100 Subject: [Cluster-devel] [GFS2 PATCH 1/2] GFS2: Move glock superblock pointer to field gl_name In-Reply-To: <1436466345-11383-2-git-send-email-rpeterso@redhat.com> References: <1436466345-11383-1-git-send-email-rpeterso@redhat.com> <1436466345-11383-2-git-send-email-rpeterso@redhat.com> Message-ID: <55A39EA6.3050302@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On 09/07/15 19:25, Bob Peterson wrote: > What uniquely identifies a glock in the glock hash table is not > gl_name, but gl_name and its superblock pointer. This patch makes > the gl_name field correspond to a unique glock identifier. That will > allow us to simplify hashing with a future patch, since the hash > algorithm can then take the gl_name and hash its components in one > operation. > --- [snip] > diff --git a/fs/gfs2/incore.h b/fs/gfs2/incore.h > index a1ec7c2..4de7853 100644 > --- a/fs/gfs2/incore.h > +++ b/fs/gfs2/incore.h > @@ -205,11 +205,13 @@ enum { > struct lm_lockname { > u64 ln_number; > unsigned int ln_type; > + struct gfs2_sbd *ln_sbd; > }; > This looks like its adding a hole on 64 bit arches... can we swap the order of ln_type and ln_sbd, or even make the sbd the first element of this? That way a memcmp of two of lm_locknames doesn't have to include the hole in the comparison, which I assume is what you want here? Steve.