Re: [PATCH 2/2] xfs/288: skip repair -n when checking empty root leaf block behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 07, 2022 at 11:08:20AM -0700, Darrick J. Wong wrote:
> 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@xxxxxxxxxx>
> > > 
> > > Update this test to reflect the (once again) corrected behavior of the
> > > xattr leaf block verifiers.
> > > 
> > > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
> > > ---
> > >  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.

Thanks for the explain.

Reviewed-by: Zorro Lang <zlang@xxxxxxxxxx>

> 
> --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"
> > > 
> > 
> 




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux