From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Tue, 13 Jul 2021 14:34:24 -0500 Subject: [Cluster-devel] [GFS2 PATCH 10/10] gfs2: replace sd_aspace with sd_inode In-Reply-To: <34e7b795c97d781b8788d965dd7caf48d8b8ec24.camel@redhat.com> References: <20210713180958.66995-1-rpeterso@redhat.com> <20210713180958.66995-11-rpeterso@redhat.com> <34e7b795c97d781b8788d965dd7caf48d8b8ec24.camel@redhat.com> Message-ID: <76779e30-76b3-b867-7d1c-46a96b56a741@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 7/13/21 1:26 PM, Steven Whitehouse wrote: > Hi, > > On Tue, 2021-07-13 at 13:09 -0500, Bob Peterson wrote: >> Before this patch, gfs2 kept its own address space for rgrps, but >> this >> caused a lockdep problem because vfs assumes a 1:1 relationship >> between >> address spaces and their inode. One problematic area is this: >> > I don't think that is the case. The reason that the address space is a > separate structure in the first place is to allow them to exist without > an inode. Maybe that has changed, but we should see why that is, in > that case rather than just making this change immediately. > > I can't see any reason why if we have to have an inode here that it > needs to be hashed... what would need to look it up via the hashes? > > Steve. > Hi, The actual use case, which is easily demonstrated with lockdep, is given in the patch text shortly after where you placed your comment. This goes back to this discussion from April 2018: https://listman.redhat.com/archives/cluster-devel/2018-April/msg00017.html in which Jan Kara pointed out that: "The problem is we really do expect mapping->host->i_mapping == mapping as we pass mapping and inode interchangebly in the mm code. The address_space and inodes are separate structures because you can have many inodes pointing to one address space (block devices). However it is not allowed for several address_spaces to point to one inode!" Regards, Bob Peterson -------------- next part -------------- An HTML attachment was scrubbed... URL: