All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
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: Wed, 29 Jun 2022 16:10:47 -0700	[thread overview]
Message-ID: <Yrzb9xFYKzvfQ/tP@magnolia> (raw)
In-Reply-To: <20220628225857.GO227878@dread.disaster.area>

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.

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

  reply	other threads:[~2022-06-29 23:10 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 [this message]
2022-06-30 22:51       ` Dave Chinner
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=Yrzb9xFYKzvfQ/tP@magnolia \
    --to=djwong@kernel.org \
    --cc=david@fromorbit.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 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.