[PATCHSET 0/3] fstests: random fixes for v2022.07.31

[PATCHSET 0/3] fstests: random fixes for v2022.07.31

[Darrick J. Wong]

Hi all,

Here's the usual batch of odd fixes for fstests.  Fix a golden output
error in the new xfs/533 test, and recycle the same "scratch fs with
not the usual scratch device" fixes.

If you're going to start using this mess, you probably ought to just
pull from my git trees, which are linked below.

This is an extraordinary way to destroy everything.  Enjoy!
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=random-fixes

xfsprogs git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=random-fixes

fstests git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=random-fixes
---
 tests/xfs/291     |    6 +-----
 tests/xfs/432     |    3 ++-
 tests/xfs/533.out |    2 +-
 3 files changed, 4 insertions(+), 7 deletions(-)

[PATCH 1/3] xfs/432: fix this test when external devices are in use

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

This program exercises metadump and mdrestore being run against the
scratch device.  Therefore, the test must pass external log / rt device
arguments to xfs_repair -n to check the "restored" filesystem.  Fix the
incorrect usage, and report repair failures, since this test has been
silently failing for a while now.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/xfs/432 |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


diff --git a/tests/xfs/432 b/tests/xfs/432
index 86012f0b..e1e610d0 100755
--- a/tests/xfs/432
+++ b/tests/xfs/432
@@ -89,7 +89,8 @@ _scratch_xfs_metadump $metadump_file -w
 xfs_mdrestore $metadump_file $metadump_img
 
 echo "Check restored metadump image"
-$XFS_REPAIR_PROG -n $metadump_img >> $seqres.full 2>&1
+SCRATCH_DEV=$metadump_img _scratch_xfs_repair -n &>> $seqres.full || \
+	echo "xfs_repair on restored fs returned $?"
 
 # success, all done
 status=0

[PATCH 2/3] xfs/291: convert open-coded _scratch_xfs_repair usage

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Convert this test to use _scratch_xfs_repair, since the only variance
from the standard usage is that it's called against a sparse file into
which the scratch filesystem has been metadumped and mdrestored.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/xfs/291 |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)


diff --git a/tests/xfs/291 b/tests/xfs/291
index 6d5e247e..a2425e47 100755
--- a/tests/xfs/291
+++ b/tests/xfs/291
@@ -93,11 +93,7 @@ _scratch_xfs_check >> $seqres.full 2>&1 || _fail "xfs_check failed"
 # Can xfs_metadump cope with this monster?
 _scratch_xfs_metadump $tmp.metadump || _fail "xfs_metadump failed"
 xfs_mdrestore $tmp.metadump $tmp.img || _fail "xfs_mdrestore failed"
-[ "$USE_EXTERNAL" = yes ] && [ -n "$SCRATCH_RTDEV" ] && \
-	rt_repair_opts="-r $SCRATCH_RTDEV"
-[ "$USE_EXTERNAL" = yes ] && [ -n "$SCRATCH_LOGDEV" ] && \
-	log_repair_opts="-l $SCRATCH_LOGDEV"
-$XFS_REPAIR_PROG $rt_repair_opts $log_repair_opts -f $tmp.img >> $seqres.full 2>&1 || \
+SCRATCH_DEV=$tmp.img _scratch_xfs_repair -f &>> $seqres.full || \
 	_fail "xfs_repair of metadump failed"
 
 # Yes it can; success, all done

[PATCH 3/3] xfs/533: fix golden output for this test

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Not sure what's up with this new test, but the golden output isn't right
for upstream xfsprogs for-next.  Change it to pass there...

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/xfs/533.out |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/tests/xfs/533.out b/tests/xfs/533.out
index 7deb78a3..439fb16e 100644
--- a/tests/xfs/533.out
+++ b/tests/xfs/533.out
@@ -1,5 +1,5 @@
 QA output created by 533
 Allowing write of corrupted data with good CRC
 magicnum = 0
-bad magic number
+Superblock has bad magic number 0x0. Not an XFS filesystem?
 0

Re: [PATCH 3/3] xfs/533: fix golden output for this test

[xuyang2018.jy]

on 2022/08/03 12:21, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Not sure what's up with this new test, but the golden output isn't right
> for upstream xfsprogs for-next.  Change it to pass there...

It failed becuase libxfs code validates v5 feature fields.

b12d5ae5d ("xfs: validate v5 feature fields")
> 
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
>   tests/xfs/533.out |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> diff --git a/tests/xfs/533.out b/tests/xfs/533.out
> index 7deb78a3..439fb16e 100644
> --- a/tests/xfs/533.out
> +++ b/tests/xfs/533.out
> @@ -1,5 +1,5 @@
>   QA output created by 533
>   Allowing write of corrupted data with good CRC
>   magicnum = 0
> -bad magic number
> +Superblock has bad magic number 0x0. Not an XFS filesystem?

Since this case is designed to detect xfs_db bug, should we filter the 
output?

Best Regards
Yang Xu
>   0
> 

Re: [PATCH 3/3] xfs/533: fix golden output for this test

[Darrick J. Wong]

On Thu, Aug 04, 2022 at 01:53:31AM +0000, xuyang2018.jy@fujitsu.com wrote:
> on 2022/08/03 12:21, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Not sure what's up with this new test, but the golden output isn't right
> > for upstream xfsprogs for-next.  Change it to pass there...
> 
> It failed becuase libxfs code validates v5 feature fields.
> 
> b12d5ae5d ("xfs: validate v5 feature fields")
> > 
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> >   tests/xfs/533.out |    2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > 
> > diff --git a/tests/xfs/533.out b/tests/xfs/533.out
> > index 7deb78a3..439fb16e 100644
> > --- a/tests/xfs/533.out
> > +++ b/tests/xfs/533.out
> > @@ -1,5 +1,5 @@
> >   QA output created by 533
> >   Allowing write of corrupted data with good CRC
> >   magicnum = 0
> > -bad magic number

Ohhh, so this is a V4 output.

> > +Superblock has bad magic number 0x0. Not an XFS filesystem?
> 
> Since this case is designed to detect xfs_db bug, should we filter the 
> output?

Yep.  I'll rework this patch to handle V4 and V5.  Well, thanks for
keeping me on my toes! ;)

--D

> Best Regards
> Yang Xu
> >   0
> > 

Re: [PATCH 3/3] xfs/533: fix golden output for this test

[Darrick J. Wong]

On Wed, Aug 03, 2022 at 10:06:16PM -0700, Darrick J. Wong wrote:
> On Thu, Aug 04, 2022 at 01:53:31AM +0000, xuyang2018.jy@fujitsu.com wrote:
> > on 2022/08/03 12:21, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <djwong@kernel.org>
> > > 
> > > Not sure what's up with this new test, but the golden output isn't right
> > > for upstream xfsprogs for-next.  Change it to pass there...
> > 
> > It failed becuase libxfs code validates v5 feature fields.
> > 
> > b12d5ae5d ("xfs: validate v5 feature fields")
> > > 
> > > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > > ---
> > >   tests/xfs/533.out |    2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > 
> > > diff --git a/tests/xfs/533.out b/tests/xfs/533.out
> > > index 7deb78a3..439fb16e 100644
> > > --- a/tests/xfs/533.out
> > > +++ b/tests/xfs/533.out
> > > @@ -1,5 +1,5 @@
> > >   QA output created by 533
> > >   Allowing write of corrupted data with good CRC
> > >   magicnum = 0
> > > -bad magic number
> 
> Ohhh, so this is a V4 output.
> 
> > > +Superblock has bad magic number 0x0. Not an XFS filesystem?
> > 
> > Since this case is designed to detect xfs_db bug, should we filter the 
> > output?
> 
> Yep.  I'll rework this patch to handle V4 and V5.  Well, thanks for
> keeping me on my toes! ;)

Hmm, V4 produces this:

--- /tmp/fstests/tests/xfs/533.out      2022-08-02 19:02:12.876335795 -0700
+++ /var/tmp/fstests/xfs/533.out.bad    2022-08-03 22:12:43.596000000 -0700
@@ -1,5 +1,3 @@
 QA output created by 533
-Allowing write of corrupted data with good CRC
 magicnum = 0
-Superblock has bad magic number 0x0. Not an XFS filesystem?
 0

So I guess this isn't a V4 output.  Which version of xfsprogs and what
MKFS_OPTIONS did you use to make this to produce 'bad magic number'?

--D

> --D
> 
> > Best Regards
> > Yang Xu
> > >   0
> > > 

Re: [PATCH 3/3] xfs/533: fix golden output for this test

[xuyang2018.jy]

on  2022/08/04 13:15, Darrick J. Wong wrote:
> On Wed, Aug 03, 2022 at 10:06:16PM -0700, Darrick J. Wong wrote:
>> On Thu, Aug 04, 2022 at 01:53:31AM +0000, xuyang2018.jy@fujitsu.com wrote:
>>> on 2022/08/03 12:21, Darrick J. Wong wrote:
>>>> From: Darrick J. Wong <djwong@kernel.org>
>>>>
>>>> Not sure what's up with this new test, but the golden output isn't right
>>>> for upstream xfsprogs for-next.  Change it to pass there...
>>>
>>> It failed becuase libxfs code validates v5 feature fields.
>>>
>>> b12d5ae5d ("xfs: validate v5 feature fields")
>>>>
>>>> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
>>>> ---
>>>>    tests/xfs/533.out |    2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>>
>>>> diff --git a/tests/xfs/533.out b/tests/xfs/533.out
>>>> index 7deb78a3..439fb16e 100644
>>>> --- a/tests/xfs/533.out
>>>> +++ b/tests/xfs/533.out
>>>> @@ -1,5 +1,5 @@
>>>>    QA output created by 533
>>>>    Allowing write of corrupted data with good CRC
>>>>    magicnum = 0
>>>> -bad magic number
>>
>> Ohhh, so this is a V4 output.
>>
>>>> +Superblock has bad magic number 0x0. Not an XFS filesystem?
>>>
>>> Since this case is designed to detect xfs_db bug, should we filter the
>>> output?
>>
>> Yep.  I'll rework this patch to handle V4 and V5.  Well, thanks for
>> keeping me on my toes! ;)
> 
> Hmm, V4 produces this:
> 
> --- /tmp/fstests/tests/xfs/533.out      2022-08-02 19:02:12.876335795 -0700
> +++ /var/tmp/fstests/xfs/533.out.bad    2022-08-03 22:12:43.596000000 -0700
> @@ -1,5 +1,3 @@
>   QA output created by 533
> -Allowing write of corrupted data with good CRC
>   magicnum = 0
> -Superblock has bad magic number 0x0. Not an XFS filesystem?
>   0
> 
> So I guess this isn't a V4 output.  Which version of xfsprogs and what
> MKFS_OPTIONS did you use to make this to produce 'bad magic number'?

I remember I used xfsprogs master branch and I don't add any special 
MKFS_OPTIONS.

meta-data=/dev/sda7              isize=512    agcount=4, agsize=3276800 blks
          =                       sectsz=4096  attr=2, projid32bit=1
          =                       crc=1        finobt=1, sparse=1, rmapbt=0
          =                       reflink=1    bigtime=1 inobtcount=1
data     =                       bsize=4096   blocks=13107200, imaxpct=25
          =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16384, version=2
          =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

local.config
MODULAR=0
export TEST_DIR=/mnt/xfstests/test
export TEST_DEV=/dev/sda6
export SCRATCH_MNT=/mnt/xfstests/scratch
export SCRATCH_DEV=/dev/sda7

I have mentioned that xfsprogs commit b12d5ae5d ("xfs: validate v5 
feature fields")  will change output to "-Superblock has bad magic 
number 0x0. Not an XFS filesystem". And this commit is belong to 
for-next branch that is why I write this case doesn't find this because 
I use master branch that time.

Best Regards
Yang Xu
> 
> --D
> 
>> --D
>>
>>> Best Regards
>>> Yang Xu
>>>>    0
>>>>

Re: [PATCH 3/3] xfs/533: fix golden output for this test

[Darrick J. Wong]

On Thu, Aug 04, 2022 at 05:31:01AM +0000, xuyang2018.jy@fujitsu.com wrote:
> 
> 
> on  2022/08/04 13:15, Darrick J. Wong wrote:
> > On Wed, Aug 03, 2022 at 10:06:16PM -0700, Darrick J. Wong wrote:
> >> On Thu, Aug 04, 2022 at 01:53:31AM +0000, xuyang2018.jy@fujitsu.com wrote:
> >>> on 2022/08/03 12:21, Darrick J. Wong wrote:
> >>>> From: Darrick J. Wong <djwong@kernel.org>
> >>>>
> >>>> Not sure what's up with this new test, but the golden output isn't right
> >>>> for upstream xfsprogs for-next.  Change it to pass there...
> >>>
> >>> It failed becuase libxfs code validates v5 feature fields.
> >>>
> >>> b12d5ae5d ("xfs: validate v5 feature fields")
> >>>>
> >>>> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> >>>> ---
> >>>>    tests/xfs/533.out |    2 +-
> >>>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>>
> >>>> diff --git a/tests/xfs/533.out b/tests/xfs/533.out
> >>>> index 7deb78a3..439fb16e 100644
> >>>> --- a/tests/xfs/533.out
> >>>> +++ b/tests/xfs/533.out
> >>>> @@ -1,5 +1,5 @@
> >>>>    QA output created by 533
> >>>>    Allowing write of corrupted data with good CRC
> >>>>    magicnum = 0
> >>>> -bad magic number
> >>
> >> Ohhh, so this is a V4 output.
> >>
> >>>> +Superblock has bad magic number 0x0. Not an XFS filesystem?
> >>>
> >>> Since this case is designed to detect xfs_db bug, should we filter the
> >>> output?
> >>
> >> Yep.  I'll rework this patch to handle V4 and V5.  Well, thanks for
> >> keeping me on my toes! ;)
> > 
> > Hmm, V4 produces this:
> > 
> > --- /tmp/fstests/tests/xfs/533.out      2022-08-02 19:02:12.876335795 -0700
> > +++ /var/tmp/fstests/xfs/533.out.bad    2022-08-03 22:12:43.596000000 -0700
> > @@ -1,5 +1,3 @@
> >   QA output created by 533
> > -Allowing write of corrupted data with good CRC
> >   magicnum = 0
> > -Superblock has bad magic number 0x0. Not an XFS filesystem?
> >   0
> > 
> > So I guess this isn't a V4 output.  Which version of xfsprogs and what
> > MKFS_OPTIONS did you use to make this to produce 'bad magic number'?
> 
> I remember I used xfsprogs master branch and I don't add any special 
> MKFS_OPTIONS.
> 
> meta-data=/dev/sda7              isize=512    agcount=4, agsize=3276800 blks
>           =                       sectsz=4096  attr=2, projid32bit=1
>           =                       crc=1        finobt=1, sparse=1, rmapbt=0
>           =                       reflink=1    bigtime=1 inobtcount=1
> data     =                       bsize=4096   blocks=13107200, imaxpct=25
>           =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
> log      =internal log           bsize=4096   blocks=16384, version=2
>           =                       sectsz=4096  sunit=1 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> local.config
> MODULAR=0
> export TEST_DIR=/mnt/xfstests/test
> export TEST_DEV=/dev/sda6
> export SCRATCH_MNT=/mnt/xfstests/scratch
> export SCRATCH_DEV=/dev/sda7
> 
> I have mentioned that xfsprogs commit b12d5ae5d ("xfs: validate v5 
> feature fields")  will change output to "-Superblock has bad magic 
> number 0x0. Not an XFS filesystem". And this commit is belong to 
> for-next branch that is why I write this case doesn't find this because 
> I use master branch that time.

Ah, sorry, I missed your mention of this commit.  Ok, so the test was
based on master (aka xfsprogs 5.18) and my corrections are based on
for-next (future xfsprogs 5.19).

Yes, I think the correct fix here is to filter the new output to match
the old.  I might throw in a _require_scratch_xfs_crc so this test
doesn't fail on (deprecated) V4 setups.

--D

> Best Regards
> Yang Xu
> > 
> > --D
> > 
> >> --D
> >>
> >>> Best Regards
> >>> Yang Xu
> >>>>    0
> >>>>

Re: [PATCH 1/3] xfs/432: fix this test when external devices are in use

[Zorro Lang]

On Tue, Aug 02, 2022 at 09:21:26PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> This program exercises metadump and mdrestore being run against the
> scratch device.  Therefore, the test must pass external log / rt device
> arguments to xfs_repair -n to check the "restored" filesystem.  Fix the
> incorrect usage, and report repair failures, since this test has been
> silently failing for a while now.
> 
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
>  tests/xfs/432 |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> 
> diff --git a/tests/xfs/432 b/tests/xfs/432
> index 86012f0b..e1e610d0 100755
> --- a/tests/xfs/432
> +++ b/tests/xfs/432
> @@ -89,7 +89,8 @@ _scratch_xfs_metadump $metadump_file -w
>  xfs_mdrestore $metadump_file $metadump_img
>  
>  echo "Check restored metadump image"
> -$XFS_REPAIR_PROG -n $metadump_img >> $seqres.full 2>&1
> +SCRATCH_DEV=$metadump_img _scratch_xfs_repair -n &>> $seqres.full || \
> +	echo "xfs_repair on restored fs returned $?"

It's good to me,

Reviewed-by: Zorro Lang <zlang@redhat.com>

If anyone has more review points, please feel free to tell us :)

>  
>  # success, all done
>  status=0
> 

Re: [PATCH 2/3] xfs/291: convert open-coded _scratch_xfs_repair usage

[Zorro Lang]

On Tue, Aug 02, 2022 at 09:21:31PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Convert this test to use _scratch_xfs_repair, since the only variance
> from the standard usage is that it's called against a sparse file into
> which the scratch filesystem has been metadumped and mdrestored.
> 
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
>  tests/xfs/291 |    6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> 
> diff --git a/tests/xfs/291 b/tests/xfs/291
> index 6d5e247e..a2425e47 100755
> --- a/tests/xfs/291
> +++ b/tests/xfs/291
> @@ -93,11 +93,7 @@ _scratch_xfs_check >> $seqres.full 2>&1 || _fail "xfs_check failed"
>  # Can xfs_metadump cope with this monster?
>  _scratch_xfs_metadump $tmp.metadump || _fail "xfs_metadump failed"
>  xfs_mdrestore $tmp.metadump $tmp.img || _fail "xfs_mdrestore failed"
> -[ "$USE_EXTERNAL" = yes ] && [ -n "$SCRATCH_RTDEV" ] && \
> -	rt_repair_opts="-r $SCRATCH_RTDEV"
> -[ "$USE_EXTERNAL" = yes ] && [ -n "$SCRATCH_LOGDEV" ] && \
> -	log_repair_opts="-l $SCRATCH_LOGDEV"
> -$XFS_REPAIR_PROG $rt_repair_opts $log_repair_opts -f $tmp.img >> $seqres.full 2>&1 || \
> +SCRATCH_DEV=$tmp.img _scratch_xfs_repair -f &>> $seqres.full || \

Good to me,

Reviewed-by: Zorro Lang <zlang@redhat.com>

Feel free to reply, if anyone has objection.

>  	_fail "xfs_repair of metadump failed"
>  
>  # Yes it can; success, all done
> 

[PATCH v1.1 3/3] xfs/533: fix false negatives for this test

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

xfsprogs 5.19 will change the error message that gets printed when the
primary superblock validation fails.  Filter the _get_metadata_field
output so that the new message looks like the old message.

While we're at it, _notrun this test on V4 filesystems because the
validation messages are in the V5 superblock validation functions.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/xfs/533 |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tests/xfs/533 b/tests/xfs/533
index afbdadac..31858cc9 100755
--- a/tests/xfs/533
+++ b/tests/xfs/533
@@ -21,13 +21,19 @@ _fixed_by_git_commit xfsprogs f4afdcb0ad11 \
 #skip fs check because invalid superblock 1
 _require_scratch_nocheck
 
+# The error messages in the golden output come from the V5 superblock verifier
+# routines, so ignore V4 filesystems.
+_require_scratch_xfs_crc
+
 _scratch_mkfs_xfs >>$seqres.full 2>&1
 
 # write the bad magicnum field value(0) to the superblock 1
 _scratch_xfs_set_metadata_field "magicnum" "0" "sb 1"
 
-#Even magicnum field has been corrupted, we still can read this field value
-_scratch_xfs_get_metadata_field "magicnum" "sb 1"
+# Even magicnum field has been corrupted, we still can read this field value.
+# The error message changed in xfsprogs 5.19.
+_scratch_xfs_get_metadata_field "magicnum" "sb 1" 2>&1 | \
+	sed -e 's/Superblock has bad magic number 0x0. Not an XFS filesystem?/bad magic number/g'
 
 # success, all done
 status=0

Re: [PATCH v1.1 3/3] xfs/533: fix false negatives for this test

[xuyang2018.jy]

on 2022/08/05 0:26, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> xfsprogs 5.19 will change the error message that gets printed when the
> primary superblock validation fails.  Filter the _get_metadata_field
> output so that the new message looks like the old message.
> 
> While we're at it, _notrun this test on V4 filesystems because the
> validation messages are in the V5 superblock validation functions.

LGTM,
Reviewed-by: Yang Xu <xuyang2018.jy@fujitsu.com>

Best Regards
Yang Xu
> 
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
>   tests/xfs/533 |   10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/xfs/533 b/tests/xfs/533
> index afbdadac..31858cc9 100755
> --- a/tests/xfs/533
> +++ b/tests/xfs/533
> @@ -21,13 +21,19 @@ _fixed_by_git_commit xfsprogs f4afdcb0ad11 \
>   #skip fs check because invalid superblock 1
>   _require_scratch_nocheck
>   
> +# The error messages in the golden output come from the V5 superblock verifier
> +# routines, so ignore V4 filesystems.
> +_require_scratch_xfs_crc
> +
>   _scratch_mkfs_xfs >>$seqres.full 2>&1
>   
>   # write the bad magicnum field value(0) to the superblock 1
>   _scratch_xfs_set_metadata_field "magicnum" "0" "sb 1"
>   
> -#Even magicnum field has been corrupted, we still can read this field value
> -_scratch_xfs_get_metadata_field "magicnum" "sb 1"
> +# Even magicnum field has been corrupted, we still can read this field value.
> +# The error message changed in xfsprogs 5.19.
> +_scratch_xfs_get_metadata_field "magicnum" "sb 1" 2>&1 | \
> +	sed -e 's/Superblock has bad magic number 0x0. Not an XFS filesystem?/bad magic number/g'
>   
>   # success, all done
>   status=0