From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Thu, 10 Dec 2015 11:29:31 -0500 (EST) Subject: [Cluster-devel] [GFS2 PATCH v3 08/14] GFS2: Don't filter out I_FREEING inodes anymore In-Reply-To: <56335560.2050604@redhat.com> References: <1445542222-30672-1-git-send-email-rpeterso@redhat.com> <1445542222-30672-9-git-send-email-rpeterso@redhat.com> <56335560.2050604@redhat.com> Message-ID: <844390874.31968879.1449764971432.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 ----- > Hi, > > On 22/10/15 20:30, Bob Peterson wrote: > > This patch basically reverts a very old patch from 2008, > > 7a9f53b3c1875bef22ad4588e818bc046ef183da, with the title > > "Alternate gfs2_iget to avoid looking up inodes being freed". > > The original patch was designed to avoid a deadlock caused by lock > > ordering with try_rgrp_unlink. The patch forced the function to not > > find inodes that were being removed by VFS. The problem is, that > > made it impossible for nodes to delete their own unlinked dinodes > > after a certain point in time, because the inode needed was not found > > by this filtering process. There is no longer a need for the patch, > > since function try_rgrp_unlink no longer locks the inode: All it does > > is queue the glock onto the delete work_queue, so there should be no > > more deadlock. > I'm not sure I understand. Why would we need to look up and inode in one > of the > I_FREEING|I_CLEAR|I_WILL_FREE states? If the inode is in one of those > states then it is already being removed, so we should be able to leave > it to its own devices and it will be gone, in the normal case. This will > also likely not be deadlock free for older kernels with the previous > workqueue implementation, but will probably be ok for upstream, > > Steve. Hi, Sorry I haven't responded earlier. I've been reworking a lot of these patches and I didn't want to respond until I got further along. This is the majority of the problem with not deleting/freeing unlinked inodes. The problem is that today, we're filtering out inodes that are I_FREEING, which means I_FREEING inodes are treated as "not found" in the code that deletes the unlinked inodes, which leaves the block out there, unlinked. What we should be doing is using the standard Linux mechanism, which means if the inode is I_FREEING, it should wait for it to be freed by vfs, IOW, block on __wait_on_freeing_inode(). When vfs (and gfs2) are done freeing the inode, a new inode will be created, and that one used for transitioning the block from unlinked to free. That closes the timing window to ensure there aren't blocks left in the UNLINKED state. The problem is that I needed to jump through some hoops to ensure that the problem fixed by reverted patch 7a9f53b3c1875bef22ad4588e818bc046ef183da wasn't reintroduced. I had to ensure it was fixed via another mechanism. Regards, Bob Peterson Red Hat File Systems