From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Brian Foster <bfoster@redhat.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 09/10] xfs_repair: add a testing hook for NEEDSREPAIR
Date: Wed, 10 Feb 2021 17:30:17 -0800 [thread overview]
Message-ID: <20210211013017.GB7193@magnolia> (raw)
In-Reply-To: <acfe3b90-9364-85d5-84e7-7a1b888bae9e@sandeen.net>
On Wed, Feb 10, 2021 at 03:41:52PM -0600, Eric Sandeen wrote:
> On 2/9/21 1:59 PM, Darrick J. Wong wrote:
> >> # ./repair/xfs_repair -c needsrepair=1 /dev/test/scratch
> >> Phase 1 - find and verify superblock...
> >> Marking filesystem in need of repair.
> >> writing modified primary superblock
> >> Phase 2 - using internal log
> >> - zero log...
> >> ERROR: The filesystem has valuable metadata changes in a log which needs to
> >> ...
> >> # mount /dev/test/scratch /mnt/
> >> mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/test-scratch, missing codepage or helper program, or other error.
> >> #
> >>
> >> It looks like we can set a feature upgrade bit on the superblock before
> >> we've examined the log and potentially discovered that it's dirty (phase
> >> 2). If the log is recoverable, that puts the user in a bit of a bind..
> > Heh, funny that I was thinking that the upgrades shouldn't really be
> > happening in phase 1 anyway--
> >
> > I've (separately) started working on a patch to make it so that you can
> > add reflink and finobt to a filesystem. Those upgrades require somewhat
> > more intensive checks of the filesystem (such as checking free space in
> > each AG), so I ended up dumping them into phase 2, since the xfs_mount
> > and buffer cache aren't fully initialized until after phase 1.
> >
> > So, yeah, the upgrade code should move to phase2() after log zeroing and
> > before the AG scan.
>
> Oh, whoops -
>
> based on this, I think that the prior patch
> [PATCH 08/10] xfs_repair: allow setting the needsrepair flag
> needs to be adjusted as well, right; we don't want to set it in phase 1
> or we might set it then abort on a dirty log and the user is stuck.
>
> So maybe I should merge up through
>
> [PATCH 07/10] xfs_repair: set NEEDSREPAIR when we deliberately corrupt directories
>
> and hold off on the rest? Or should I just hold off on the series and let
> you reassemble (again?)
Yeah, I'll push out v5 tomorrow morning with all this cleaned up.
--D
> (Am I right that the upgrade bits will need to be moved and the series resent?)
>
> -Eric
next prev parent reply other threads:[~2021-02-11 1:31 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 4:10 [PATCHSET v4 00/10] xfs: add the ability to flag a fs for repair Darrick J. Wong
2021-02-09 4:10 ` [PATCH 01/10] xfs_admin: clean up string quoting Darrick J. Wong
2021-02-09 9:07 ` Christoph Hellwig
2021-02-09 4:10 ` [PATCH 02/10] xfs_admin: support filesystems with realtime devices Darrick J. Wong
2021-02-09 9:08 ` Christoph Hellwig
2021-02-09 17:19 ` Brian Foster
2021-02-09 4:10 ` [PATCH 03/10] xfs_db: support the needsrepair feature flag in the version command Darrick J. Wong
2021-02-09 9:09 ` Christoph Hellwig
2021-02-09 17:15 ` Darrick J. Wong
2021-02-09 17:19 ` Brian Foster
2021-02-09 4:10 ` [PATCH 04/10] xfs_repair: fix unmount error message to have a newline Darrick J. Wong
2021-02-09 9:09 ` Christoph Hellwig
2021-02-09 4:10 ` [PATCH 05/10] xfs_repair: clear quota CHKD flags on the incore superblock too Darrick J. Wong
2021-02-09 9:10 ` Christoph Hellwig
2021-02-09 17:20 ` Brian Foster
2021-02-09 17:46 ` Darrick J. Wong
2021-02-09 4:10 ` [PATCH 06/10] xfs_repair: clear the needsrepair flag Darrick J. Wong
2021-02-09 9:12 ` Christoph Hellwig
2021-02-09 17:20 ` Brian Foster
2021-02-09 18:01 ` Darrick J. Wong
2021-02-09 4:10 ` [PATCH 07/10] xfs_repair: set NEEDSREPAIR when we deliberately corrupt directories Darrick J. Wong
2021-02-09 9:13 ` Christoph Hellwig
2021-02-09 18:45 ` Darrick J. Wong
2021-02-09 17:20 ` Brian Foster
2021-02-09 18:35 ` Darrick J. Wong
2021-02-09 19:14 ` Brian Foster
2021-02-09 19:43 ` Darrick J. Wong
2021-02-10 20:19 ` Eric Sandeen
2021-02-09 4:10 ` [PATCH 08/10] xfs_repair: allow setting the needsrepair flag Darrick J. Wong
2021-02-09 9:15 ` Christoph Hellwig
2021-02-09 14:41 ` Eric Sandeen
2021-02-09 16:47 ` Darrick J. Wong
2021-02-10 20:44 ` Eric Sandeen
2021-02-09 17:21 ` Brian Foster
2021-02-09 18:10 ` Darrick J. Wong
2021-02-10 20:26 ` Eric Sandeen
2021-02-09 4:10 ` [PATCH 09/10] xfs_repair: add a testing hook for NEEDSREPAIR Darrick J. Wong
2021-02-09 9:16 ` Christoph Hellwig
2021-02-09 17:21 ` Brian Foster
2021-02-09 18:17 ` Darrick J. Wong
2021-02-09 18:59 ` Brian Foster
2021-02-09 19:59 ` Darrick J. Wong
2021-02-09 20:32 ` Brian Foster
2021-02-10 21:41 ` Eric Sandeen
2021-02-11 1:30 ` Darrick J. Wong [this message]
2021-02-09 4:11 ` [PATCH 10/10] xfs_admin: support adding features to V5 filesystems Darrick J. Wong
2021-02-09 9:18 ` Christoph Hellwig
2021-02-09 17:22 ` Brian Foster
2021-02-09 18:22 ` 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=20210211013017.GB7193@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