All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Zorro Lang <zlang@redhat.com>
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs/288: skip repair -n when checking empty root leaf block behavior
Date: Thu, 7 Jul 2022 11:08:20 -0700	[thread overview]
Message-ID: <YschFMW4rVuQz9Mi@magnolia> (raw)
In-Reply-To: <20220707122525.so6alaa63hdz3bbx@zlang-mailbox>

On Thu, Jul 07, 2022 at 08:25:25PM +0800, Zorro Lang wrote:
> On Tue, Jul 05, 2022 at 03:02:34PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Update this test to reflect the (once again) corrected behavior of the
> > xattr leaf block verifiers.
> > 
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> >  tests/xfs/288 |   32 +++++++++++++-------------------
> >  1 file changed, 13 insertions(+), 19 deletions(-)
> > 
> > 
> > diff --git a/tests/xfs/288 b/tests/xfs/288
> > index e3d230e9..aa664a26 100755
> > --- a/tests/xfs/288
> > +++ b/tests/xfs/288
> > @@ -8,7 +8,7 @@
> >  # that leaf directly (as xfsprogs commit f714016).
> >  #
> >  . ./common/preamble
> > -_begin_fstest auto quick repair fuzzers
> > +_begin_fstest auto quick repair fuzzers attr
> >  
> >  # Import common functions.
> >  . ./common/filter
> > @@ -50,25 +50,19 @@ if [ "$count" != "0" ]; then
> >  	_notrun "xfs_db can't set attr hdr.count to 0"
> >  fi
> >  
> > -# make sure xfs_repair can find above corruption. If it can't, that
> > -# means we need to fix this bug on current xfs_repair
> > -_scratch_xfs_repair -n >> $seqres.full 2>&1
> 
> So we drop the `xfs_repair -n` test.

Yep.

> Will the latest xfs_repair fail or pass on that? I'm wondering what's the expect
> result of `xfs_repair -n` on a xfs with empty leaf? Should it report errors,
> or nothing wrong?

xfs_repair -n no longer fails on attr block 0 being an empty leaf block
since those are part of the ondisk format and are not a corruption.

xfs_repair (without the -n) will clear the attr fork since there aren't
any xattrs if attr block 0 is empty.

--D

> Thanks,
> Zorro
> 
> > -if [ $? -eq 0 ];then
> > -	_fail "xfs_repair can't find the corruption"
> > -else
> > -	# If xfs_repair can find this corruption, then this repair
> > -	# should junk above leaf attribute and fix this XFS.
> > -	_scratch_xfs_repair >> $seqres.full 2>&1
> > +# Check that xfs_repair discards the attr fork if block 0 is an empty leaf
> > +# block.  Empty leaf blocks at the start of the xattr data can be a byproduct
> > +# of a shutdown race, and hence are not a corruption.
> > +_scratch_xfs_repair >> $seqres.full 2>&1
> >  
> > -	# Old xfs_repair maybe find and fix this corruption by
> > -	# reset the first used heap value and the usedbytes cnt
> > -	# in ablock 0. That's not what we want. So check if
> > -	# xfs_repair has junked the whole ablock 0 by xfs_db.
> > -	_scratch_xfs_db -x -c "inode $inum" -c "ablock 0" | \
> > -		grep -q "no attribute data"
> > -	if [ $? -ne 0 ]; then
> > -		_fail "xfs_repair didn't junk the empty attr leaf"
> > -	fi
> > +# Old xfs_repair maybe find and fix this corruption by
> > +# reset the first used heap value and the usedbytes cnt
> > +# in ablock 0. That's not what we want. So check if
> > +# xfs_repair has junked the whole ablock 0 by xfs_db.
> > +_scratch_xfs_db -x -c "inode $inum" -c "ablock 0" | \
> > +	grep -q "no attribute data"
> > +if [ $? -ne 0 ]; then
> > +	_fail "xfs_repair didn't junk the empty attr leaf"
> >  fi
> >  
> >  echo "Silence is golden"
> > 
> 

  reply	other threads:[~2022-07-07 18:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-05 22:02 [PATCHSET 0/2] fstests: new tests for kernel 5.19 Darrick J. Wong
2022-07-05 22:02 ` [PATCH 1/2] xfs: make sure that we handle empty xattr leaf blocks ok Darrick J. Wong
2022-07-07 12:06   ` Zorro Lang
2022-07-07 18:22     ` Darrick J. Wong
2022-07-08  0:49       ` Zorro Lang
2022-07-08 15:08         ` Darrick J. Wong
2022-07-08 15:32   ` [PATCH v1.1 " Darrick J. Wong
2022-07-08 16:30     ` Zorro Lang
2022-07-08 16:56       ` Darrick J. Wong
2022-07-08 17:02   ` [PATCH " Darrick J. Wong
2022-07-08 17:08     ` Zorro Lang
2022-07-08 17:27       ` Zorro Lang
2022-07-08 17:46         ` Darrick J. Wong
2022-07-08 18:19           ` Zorro Lang
2022-07-08 17:44   ` [PATCH v1.3 " Darrick J. Wong
2022-07-05 22:02 ` [PATCH 2/2] xfs/288: skip repair -n when checking empty root leaf block behavior Darrick J. Wong
2022-07-07 12:25   ` Zorro Lang
2022-07-07 18:08     ` Darrick J. Wong [this message]
2022-07-08 15:47       ` Zorro Lang

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=YschFMW4rVuQz9Mi@magnolia \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@redhat.com \
    /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.