From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Wed, 26 Aug 2015 10:12:20 -0400 (EDT) Subject: [Cluster-devel] [GFS2 PATCH 1/2][TRY #2] GFS2: Move glock superblock pointer to field gl_name In-Reply-To: References: <1436466345-11383-1-git-send-email-rpeterso@redhat.com> <1436466345-11383-2-git-send-email-rpeterso@redhat.com> <55A39EA6.3050302@redhat.com> <910441860.37476260.1436794765629.JavaMail.zimbra@redhat.com> <55A40F47.1080002@redhat.com> Message-ID: <653028784.17322751.1440598340513.JavaMail.zimbra@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----- Original Message ----- > Bob, > > how hard would it be to move the rhashtable into struct gfs2_sbd instead? > > Thanks, > Andreas Hi Andreas, I've suggested moving the glock hash table into the superblock a couple times in the past, when it was still a normal hash table, but I've always been shot down. The advantage was improved scalability and not having to filter out the glocks you don't want from the ones you don't when you go to do things like dumping glocks. There's one central point for all glocks everywhere. With rhashtable, scalability isn't much of an issue anymore. The disadvantage is having multiple hash tables to manage when you are trying to clear things out when you're unloading the module, for example. I've always felt the advantages outweighed the disadvantages, but others did not agree. Regards, Bob Peterson Red Hat File Systems