From: "Darrick J. Wong" <djwong@kernel.org>
To: Brian Foster <bfoster@redhat.com>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs_repair: clear the needsrepair flag
Date: Tue, 19 Jan 2021 15:49:57 -0800 [thread overview]
Message-ID: <20210119234819.GV3134581@magnolia> (raw)
In-Reply-To: <20210119203110.GT3134581@magnolia>
On Tue, Jan 19, 2021 at 12:31:10PM -0800, Darrick J. Wong wrote:
> On Tue, Jan 19, 2021 at 02:44:06PM -0500, Brian Foster wrote:
> > On Tue, Jan 19, 2021 at 10:15:49AM -0800, Darrick J. Wong wrote:
> > > On Tue, Jan 19, 2021 at 09:37:54AM -0500, Brian Foster wrote:
> > > > On Fri, Jan 15, 2021 at 05:24:53PM -0800, Darrick J. Wong wrote:
> > > > > From: Darrick J. Wong <djwong@kernel.org>
> > > > >
> > > > > Clear the needsrepair flag, since it's used to prevent mounting of an
> > > > > inconsistent filesystem.
> > > > >
> > > > > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > > > > ---
> > > >
> > > > Code/errors look much cleaner. Though looking at the repair code again,
> > > > I wonder... if we clear the needsrepair bit and dirty/write the sb in
> > > > phase 2 and then xfs_repair happens to crash, do we risk clearing the
> > > > bit and thus allowing a potential mount before whatever requisite
> > > > metadata updates have been made?
> > >
> > > [Oh good, now mail.kernel.org is having problems...]
> > >
> > > Yes, though I think that falls into the realm of "sysadmins should be
> > > sufficiently self-aware not to expect mount to work after repair
> > > fails/system crashes during an upgrade".
> > >
> > > I've thought about how to solve the general problem of preventing people
> > > from mounting filesystems if repair doesn't run to completion. I think
> > > xfs_repair could be modified so that once it finds the primary super, it
> > > writes it back out with NEEDSREPAIR set (V5) or inprogress set (V4).
> > > Once we've finished the buffer cache flush at the end of repair, we
> > > clear needsrepair/inprogress and write the primary super again.
> > >
> >
> > That's kind of what I was thinking.. set a global flag if/when we come
> > across the bit set on disk and clear it as a final step.
>
> I think if I found it set on the primary sb I would leave it alone, and
> if the bit wasn't set then I'd set it and bwrite the buffer immediately.
> Probably we're talking about more or less the same thing...
...though after talking to Eric some more, I think I should change this
patch to clear needsrepair at the end of repair, like you said.
--D
> > > An optimization on that would be to find a way to avoid that first super
> > > write until we flush the first dirty buffer.
> > >
> > > Another way to make repair more "transactional" would be to do it would
> > > be to fiddle with the buffer manager so that writes are sent to a
> > > metadump file which could be mdrestore'd if repair completes
> > > successfully. But that's a short-circuit around the even bigger project
> > > of porting the kernel logging code to userspace and use that in repair.
> > >
> >
> > Yeah, I wouldn't want to have clearing a feature bit depend on such a
> > significant rework of core functionality. The bit is not going to be set
> > in most cases, so I'd suspect an extra superblock write at the end of
> > repair wouldn't be much of a problem. In fact, it looks like main()
> > already has an unconditional sb write before the final libxfs_unmount()
> > call. Perhaps we could just hitch onto that for the primary super
> > update (and continue to clear the secondaries earlier as the current
> > patch does)..?
>
> Clearing the bit has to happen after the bcache purge and disk flush,
> because we need to make sure that everything else we wrote actually made
> it to stable storage.
>
> Hm, I guess we could export libxfs_flush_mount so that repair could call
> that, clear the fields in the sb, and then go ahead with the
> libxfs_umount.
>
> --D
>
> > Brian
> >
> > > --D
> > >
> > > > Brian
> > > >
> > > > > repair/agheader.c | 15 +++++++++++++++
> > > > > 1 file changed, 15 insertions(+)
> > > > >
> > > > >
> > > > > diff --git a/repair/agheader.c b/repair/agheader.c
> > > > > index 8bb99489..d9b72d3a 100644
> > > > > --- a/repair/agheader.c
> > > > > +++ b/repair/agheader.c
> > > > > @@ -452,6 +452,21 @@ secondary_sb_whack(
> > > > > rval |= XR_AG_SB_SEC;
> > > > > }
> > > > >
> > > > > + if (xfs_sb_version_needsrepair(sb)) {
> > > > > + if (!no_modify)
> > > > > + sb->sb_features_incompat &=
> > > > > + ~XFS_SB_FEAT_INCOMPAT_NEEDSREPAIR;
> > > > > + if (i == 0) {
> > > > > + if (!no_modify)
> > > > > + do_warn(
> > > > > + _("clearing needsrepair flag and regenerating metadata\n"));
> > > > > + else
> > > > > + do_warn(
> > > > > + _("would clear needsrepair flag and regenerate metadata\n"));
> > > > > + }
> > > > > + rval |= XR_AG_SB_SEC;
> > > > > + }
> > > > > +
> > > > > return(rval);
> > > > > }
> > > > >
> > > > >
> > > >
> > >
> >
next prev parent reply other threads:[~2021-01-19 23:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-16 1:24 [PATCHSET v2 0/2] xfs: add the ability to flag a fs for repair Darrick J. Wong
2021-01-16 1:24 ` [PATCH 1/2] xfs_db: support the needsrepair feature flag in the version command Darrick J. Wong
2021-01-19 14:37 ` Brian Foster
2021-02-02 21:09 ` Darrick J. Wong
2021-02-03 13:07 ` Brian Foster
2021-02-03 18:30 ` Darrick J. Wong
2021-02-03 19:09 ` Brian Foster
2021-01-16 1:24 ` [PATCH 2/2] xfs_repair: clear the needsrepair flag Darrick J. Wong
2021-01-19 14:37 ` Brian Foster
2021-01-19 18:15 ` Darrick J. Wong
2021-01-19 19:44 ` Brian Foster
2021-01-19 20:31 ` Darrick J. Wong
2021-01-19 23:49 ` Darrick J. Wong [this message]
2021-01-20 4:31 ` [PATCH v2.1 " Darrick J. Wong
2021-01-20 17:38 ` Brian Foster
2021-02-02 22:22 ` Darrick J. Wong
2021-01-20 4:31 ` [PATCH 3/2] xfs_repair: fix unmount error message to have a newline Darrick J. Wong
2021-01-20 17:38 ` Brian Foster
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=20210119234819.GV3134581@magnolia \
--to=djwong@kernel.org \
--cc=bfoster@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--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).