From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/6] xfs_repair: clear DIFLAG2_NREXT64 when filesystem doesn't support nrext64
Date: Fri, 1 Jul 2022 08:51:45 +1000 [thread overview]
Message-ID: <20220630225145.GB227878@dread.disaster.area> (raw)
In-Reply-To: <Yrzb9xFYKzvfQ/tP@magnolia>
On Wed, Jun 29, 2022 at 04:10:47PM -0700, Darrick J. Wong wrote:
> On Wed, Jun 29, 2022 at 08:58:57AM +1000, Dave Chinner wrote:
> > On Tue, Jun 28, 2022 at 01:49:25PM -0700, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <djwong@kernel.org>
> > >
> > > Clear the nrext64 inode flag if the filesystem doesn't have the nrext64
> > > feature enabled in the superblock.
> > >
> > > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > > ---
> > > repair/dinode.c | 19 +++++++++++++++++++
> > > 1 file changed, 19 insertions(+)
> > >
> > >
> > > diff --git a/repair/dinode.c b/repair/dinode.c
> > > index 00de31fb..547c5833 100644
> > > --- a/repair/dinode.c
> > > +++ b/repair/dinode.c
> > > @@ -2690,6 +2690,25 @@ _("bad (negative) size %" PRId64 " on inode %" PRIu64 "\n"),
> > > }
> > > }
> > >
> > > + if (xfs_dinode_has_large_extent_counts(dino) &&
> > > + !xfs_has_large_extent_counts(mp)) {
> > > + if (!uncertain) {
> > > + do_warn(
> > > + _("inode %" PRIu64 " is marked large extent counts but file system does not support large extent counts\n"),
> > > + lino);
> > > + }
> > > + flags2 &= ~XFS_DIFLAG2_NREXT64;
> > > +
> > > + if (no_modify) {
> > > + do_warn(_("would zero extent counts.\n"));
> > > + } else {
> > > + do_warn(_("zeroing extent counts.\n"));
> > > + dino->di_nextents = 0;
> > > + dino->di_anextents = 0;
> > > + *dirty = 1;
> >
> > Is that necessary? If the existing extent counts are within the
> > bounds of the old extent fields, then shouldn't we just rewrite the
> > current values into the old format rather than trashing all the
> > data/xattrs on the inode?
>
> It's hard to know what to do here -- we haven't actually checked the
> forks yet, so we don't know if the dinode flag was set but the !nrext64
> extent count fields are ok so all we have to do is clear the dinode
> flag; or if the dinode flag was set, the nrext64 extent count fields are
> correct and must be moved to the !nrext64 fields; or what?
>
> I guess I could just leave the extent count fields as-is and let the
> process_*_fork functions deal with it.
Can we check it -after- the inode has otherwise been validated
and do the conversion then?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2022-06-30 22:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 20:49 [PATCHSET 0/6] xfsprogs: random fixes Darrick J. Wong
2022-06-28 20:49 ` [PATCH 1/6] xfs_copy: don't use cached buffer reads until after libxfs_mount Darrick J. Wong
2022-06-28 22:56 ` Dave Chinner
2022-06-29 7:44 ` Christoph Hellwig
2022-06-28 20:49 ` [PATCH 2/6] xfs_repair: clear DIFLAG2_NREXT64 when filesystem doesn't support nrext64 Darrick J. Wong
2022-06-28 22:58 ` Dave Chinner
2022-06-29 23:10 ` Darrick J. Wong
2022-06-30 22:51 ` Dave Chinner [this message]
2022-07-01 0:08 ` Darrick J. Wong
2022-07-01 0:12 ` [PATCH v2 " Darrick J. Wong
2022-07-01 1:08 ` Dave Chinner
2022-06-28 20:49 ` [PATCH 3/6] xfs_repair: detect and fix padding fields that changed with nrext64 Darrick J. Wong
2022-06-28 22:59 ` Dave Chinner
2022-06-28 20:49 ` [PATCH 4/6] mkfs: preserve DIFLAG2_NREXT64 when setting other inode attributes Darrick J. Wong
2022-06-28 22:59 ` Dave Chinner
2022-06-28 20:49 ` [PATCH 5/6] mkfs: document the large extent count switch in the --help screen Darrick J. Wong
2022-06-28 23:00 ` Dave Chinner
2022-06-28 20:49 ` [PATCH 6/6] mkfs: always use new_diflags2 to initialize new inodes Darrick J. Wong
2022-06-28 23:01 ` Dave Chinner
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=20220630225145.GB227878@dread.disaster.area \
--to=david@fromorbit.com \
--cc=djwong@kernel.org \
--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 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.