All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zorro Lang <zlang@redhat.com>
To: "Darrick J. Wong" <djwong@kernel.org>
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 20:25:25 +0800	[thread overview]
Message-ID: <20220707122525.so6alaa63hdz3bbx@zlang-mailbox> (raw)
In-Reply-To: <165705855433.2821854.6003804324518144422.stgit@magnolia>

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.

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?

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 12:25 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 [this message]
2022-07-07 18:08     ` Darrick J. Wong
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=20220707122525.so6alaa63hdz3bbx@zlang-mailbox \
    --to=zlang@redhat.com \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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.