cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH v3 08/14] GFS2: Don't filter out I_FREEING inodes anymore
Date: Thu, 10 Dec 2015 11:29:31 -0500 (EST)	[thread overview]
Message-ID: <844390874.31968879.1449764971432.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <56335560.2050604@redhat.com>

----- 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



  reply	other threads:[~2015-12-10 16:29 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-22 19:30 [Cluster-devel] [GFS2 PATCH v3 00/14] Fourteen patches related to file unlink->delete->new Bob Peterson
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 01/14] GFS2: Update master statfs buffer with sd_statfs_spin locked Bob Peterson
2015-10-30 10:49   ` Steven Whitehouse
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 02/14] GFS2: Allow fail_gunlock3 to set the free_vfs_inode bit Bob Peterson
2015-10-30 11:07   ` Steven Whitehouse
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 03/14] GFS2: Protect log tail calculations with inside locks Bob Peterson
2015-10-30 11:14   ` Steven Whitehouse
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 04/14] GFS2: Wait for iopen glock dequeues Bob Peterson
2015-10-30 11:14   ` Steven Whitehouse
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 05/14] GFS2: Reintroduce a timeout in function gfs2_gl_hash_clear Bob Peterson
2015-10-30 11:18   ` Steven Whitehouse
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 06/14] GFS2: Prevent gl_delete work for re-used inodes Bob Peterson
2015-10-30 11:23   ` Steven Whitehouse
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 07/14] GFS2: Truncate address space mapping when deleting an inode Bob Peterson
2015-10-30 11:27   ` Steven Whitehouse
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 08/14] GFS2: Don't filter out I_FREEING inodes anymore Bob Peterson
2015-10-30 11:32   ` Steven Whitehouse
2015-12-10 16:29     ` Bob Peterson [this message]
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 09/14] GFS2: generalize gfs2_check_blk_type Bob Peterson
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 10/14] GFS2: Change from tr_touched to tr_bufs Bob Peterson
2015-10-30 11:47   ` Steven Whitehouse
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 11/14] GFS2: Add new function gfs2_inode_lookup_for_del Bob Peterson
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 12/14] gfs2: Remove unused param non_block from gfs2_inode_lookup Bob Peterson
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 13/14] GFS2: Hold onto iopen glock longer when dinode creation fails Bob Peterson
2015-10-22 19:30 ` [Cluster-devel] [GFS2 PATCH v3 14/14] GFS2: Rework gfs2_evict_inode to prevent collisions with openers Bob Peterson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=844390874.31968879.1449764971432.JavaMail.zimbra@redhat.com \
    --to=rpeterso@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).