From: Brian Foster <bfoster@redhat.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs: do not log/recover swapext extent owner changes for deleted inodes
Date: Mon, 26 Feb 2018 11:39:51 -0500 [thread overview]
Message-ID: <20180226163951.GC51394@bfoster.bfoster> (raw)
In-Reply-To: <f2dcef25-01f2-d7fe-3b2d-f54a809215a5@redhat.com>
On Fri, Feb 23, 2018 at 05:49:41PM -0600, Eric Sandeen wrote:
> Today if we run swapext and crash, log replay can fail because
> the recovery code tries to instantiate the donor inode from
> disk to replay the swapext, but it's been deleted and we throw
> corruption failures if we try to get an inode off disk with
> i_mode == 0.
>
> This fixes both sides: We don't log the swapext change if the
> inode has been deleted, and we don't try to recover it either.
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
>
> diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c
> index 26f2413..de48eb8 100644
> --- a/fs/xfs/xfs_inode_item.c
> +++ b/fs/xfs/xfs_inode_item.c
> @@ -436,6 +436,12 @@ xfs_inode_item_format(
> ~(XFS_ILOG_ADATA | XFS_ILOG_ABROOT | XFS_ILOG_AEXT);
> }
>
> + /* If this inode has been deleted do not log swapext owner changes */
> + if (VFS_I(ip)->i_mode == 0) {
> + ilf->ilf_fields &= ~(XFS_ILOG_DOWNER | XFS_ILOG_AOWNER);
> + iip->ili_fields &= ~(XFS_ILOG_DOWNER | XFS_ILOG_AOWNER);
> + }
> +
Do you have any more details on the context that leads to this issue?
More specifically, is the problem limited to/because of the case where
the inode is relogged and the owner change flag carries forward to the
transaction that ultimately frees it (which seems to me is what the
above prevents)? Or is there some other scenario that can lead to this?
I guess I'm kind of wondering if this can still happen in spite of the
above, if the extent swap -> unlink happens in separate log formats and
the inode happens to be written back before a crash and the log tail
being unpinned. Now that I think of it I suppose the log recovery lsn
ordering should prevent that kind of thing on v5 filesystems, at least.
Note that I'd expect the log recovery side change to detect that
regardless, I'm more just wondering if we need both if the above is not
necessarily sufficient.
Brian
> /* update the format with the exact fields we actually logged */
> ilf->ilf_fields |= (iip->ili_fields & ~XFS_ILOG_TIMESTAMP);
> }
> diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> index 5e219d9..d0e33b9 100644
> --- a/fs/xfs/xfs_log_recover.c
> +++ b/fs/xfs/xfs_log_recover.c
> @@ -3199,7 +3199,9 @@ xlog_recover_inode_pass2(
> }
>
> out_owner_change:
> - if (in_f->ilf_fields & (XFS_ILOG_DOWNER|XFS_ILOG_AOWNER))
> + /* Recover the swapext owner change unless inode has been deleted */
> + if ((in_f->ilf_fields & (XFS_ILOG_DOWNER|XFS_ILOG_AOWNER)) &&
> + (dip->di_mode != 0))
> error = xfs_recover_inode_owner_change(mp, dip, in_f,
> buffer_list);
> /* re-generate the checksum. */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-02-26 16:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-23 23:49 [PATCH] xfs: do not log/recover swapext extent owner changes for deleted inodes Eric Sandeen
2018-02-26 16:39 ` Brian Foster [this message]
2018-02-26 20:56 ` Brian Foster
2018-03-07 19:58 ` Eric Sandeen
2018-03-08 19:46 ` Brian Foster
2018-03-24 0:13 ` [PATCH V2] xfs: do not log " Eric Sandeen
2018-03-24 1:03 ` Darrick J. Wong
2018-03-26 12:13 ` Brian Foster
2018-03-26 13:37 ` Eric Sandeen
2018-03-28 22:12 ` [PATCH V3] xfs: do not log/recover " Eric Sandeen
2018-03-29 13:19 ` Brian Foster
2018-03-29 13:26 ` Eric Sandeen
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=20180226163951.GC51394@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@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).