From: Brian Foster <bfoster@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Eric Sandeen <sandeen@redhat.com>, linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH 1/2] xfs: always check for and process unlinked inodes on mount
Date: Thu, 15 Mar 2018 08:17:18 -0400 [thread overview]
Message-ID: <20180315121717.GA45325@bfoster.bfoster> (raw)
In-Reply-To: <d35d1067-a6f6-09be-9c4c-3e08a3bec3be@sandeen.net>
On Wed, Mar 07, 2018 at 05:32:29PM -0600, Eric Sandeen wrote:
> Process any unlinked inodes unconditionally; this allows us to
> skip dirtying the log on frozen filesystems and still have
> proper recovery on the next mount.
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
>
> diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> index 1937a93..2a645c0 100644
> --- a/fs/xfs/xfs_log_recover.c
> +++ b/fs/xfs/xfs_log_recover.c
> @@ -5854,8 +5854,6 @@ static inline bool xlog_item_is_intent(struct xfs_log_item *lip)
> */
> xfs_log_force(log->l_mp, XFS_LOG_SYNC);
>
> - xlog_recover_process_iunlinks(log);
> -
> xlog_recover_check_summary(log);
>
> xfs_notice(log->l_mp, "Ending recovery (logdev: %s)",
> @@ -5865,6 +5863,14 @@ static inline bool xlog_item_is_intent(struct xfs_log_item *lip)
> } else {
> xfs_info(log->l_mp, "Ending clean mount");
> }
> +
> + /*
> + * Process any unlinked inodes unconditionally, this allows us to
> + * skip dirtying the log on frozen filesystems and still have
> + * proper recovery on the next mount.
> + */
> + xlog_recover_process_iunlinks(log);
> +
The code seems fine. The only nit I have is maybe we should pull down
the "Ending ..." messages until after the iunlinks call.
That aside, this does introduce the same kind of mount delay we've been
batting around wrt to the agfl padding fixup thing. We already have the
scan in some places (perag reservation init calculations, cow blocks
scan), some of which may be able to be removed/replaced going forward. I
think this one falls into the latter category as well, but I'd be fine
with this for the time being so long as the benefit is valuable enough.
Have we considered anything like conditionally dirtying the log on
freeze only when there are open+unlinked files? It seems like that may
be uncommon enough to address the problem for snapshot users
(particularly the read-only use case mentioned in the cover letter), but
that's just a guess.
Brian
> return 0;
> }
>
>
> --
> 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-03-15 12:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-07 23:31 [PATCH 0/2] xfs: don't require a dirty log on snapshots Eric Sandeen
2018-03-07 23:32 ` [PATCH 1/2] xfs: always check for and process unlinked inodes on mount Eric Sandeen
2018-03-08 0:41 ` Eric Sandeen
2018-03-15 12:17 ` Brian Foster [this message]
2018-03-15 12:19 ` Eric Sandeen
2018-03-15 12:41 ` Brian Foster
2018-03-07 23:33 ` [PATCH 2/2] xfs: don't dirty snapshot logs for unlinked inode recovery Eric Sandeen
2018-03-24 16:20 ` Darrick J. Wong
2018-03-26 12:46 ` Brian Foster
2018-03-27 21:17 ` Dave Chinner
2021-02-23 13:42 ` Gao Xiang
2021-02-23 14:40 ` Eric Sandeen
2021-02-23 15:03 ` Gao Xiang
2021-02-23 15:46 ` Eric Sandeen
2021-02-23 15:58 ` Gao Xiang
2021-02-23 16:25 ` Darrick J. Wong
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=20180315121717.GA45325@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=sandeen@sandeen.net \
/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).