From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
Eric Sandeen <sandeen@redhat.com>,
linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH 2/2] xfs: don't dirty snapshot logs for unlinked inode recovery
Date: Mon, 26 Mar 2018 08:46:49 -0400 [thread overview]
Message-ID: <20180326124649.GD34912@bfoster.bfoster> (raw)
In-Reply-To: <20180324162049.GP4818@magnolia>
On Sat, Mar 24, 2018 at 09:20:49AM -0700, Darrick J. Wong wrote:
> On Wed, Mar 07, 2018 at 05:33:48PM -0600, Eric Sandeen wrote:
> > Now that unlinked inode recovery is done outside of
> > log recovery, there is no need to dirty the log on
> > snapshots just to handle unlinked inodes. This means
> > that readonly snapshots can be mounted without requiring
> > -o ro,norecovery to avoid the log replay that can't happen
> > on a readonly block device.
> >
> > (unlinked inodes will just hang out in the agi buckets until
> > the next writable mount)
>
> FWIW I put these two in a test kernel to see what would happen and
> generic/311 failures popped up. It looked like the _check_scratch_fs
> found incorrect block counts on the snapshot(?)
>
Interesting. Just a wild guess, but perhaps it has something to do with
lazy sb accounting..? I see we call xfs_initialize_perag_data() when
mounting an unclean fs.
Brian
> --D
>
> > Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> > ---
> >
> > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> > index 93588ea..5669525 100644
> > --- a/fs/xfs/xfs_super.c
> > +++ b/fs/xfs/xfs_super.c
> > @@ -1419,9 +1419,10 @@ struct proc_xfs_info {
> >
> > /*
> > * Second stage of a freeze. The data is already frozen so we only
> > - * need to take care of the metadata. Once that's done sync the superblock
> > - * to the log to dirty it in case of a crash while frozen. This ensures that we
> > - * will recover the unlinked inode lists on the next mount.
> > + * need to take care of the metadata.
> > + * Any unlinked inode lists will remain at this point, and be recovered
> > + * on the next writable mount if we crash while frozen, or create
> > + * a snapshot from the frozen filesystem.
> > */
> > STATIC int
> > xfs_fs_freeze(
> > @@ -1431,7 +1432,7 @@ struct proc_xfs_info {
> >
> > xfs_save_resvblks(mp);
> > xfs_quiesce_attr(mp);
> > - return xfs_sync_sb(mp, true);
> > + return 0;
> > }
> >
> > STATIC int
> >
> > --
> > 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
> --
> 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-26 12:46 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
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 [this message]
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=20180326124649.GD34912@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=darrick.wong@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.