linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/4] xfs: set bnobt/cntbt numrecs correctly when formatting new AGs
Date: Thu, 27 Apr 2023 21:29:05 -0700	[thread overview]
Message-ID: <20230428042905.GJ59213@frogsfrogsfrogs> (raw)
In-Reply-To: <20230428021125.GO3223426@dread.disaster.area>

On Fri, Apr 28, 2023 at 12:11:25PM +1000, Dave Chinner wrote:
> On Thu, Apr 27, 2023 at 03:49:05PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Through generic/300, I discovered that mkfs.xfs creates corrupt
> > filesystems when given these parameters:
> > 
> > # mkfs.xfs -d size=512M /dev/sda -f -d su=128k,sw=4 --unsupported
> > Filesystems formatted with --unsupported are not supported!!
> > meta-data=/dev/sda               isize=512    agcount=8, agsize=16352 blks
> >          =                       sectsz=512   attr=2, projid32bit=1
> >          =                       crc=1        finobt=1, sparse=1, rmapbt=1
> >          =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
> > data     =                       bsize=4096   blocks=130816, imaxpct=25
> >          =                       sunit=32     swidth=128 blks
> > naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
> > log      =internal log           bsize=4096   blocks=8192, version=2
> >          =                       sectsz=512   sunit=32 blks, lazy-count=1
> > realtime =none                   extsz=4096   blocks=0, rtextents=0
> >          =                       rgcount=0    rgsize=0 blks
> > Discarding blocks...Done.
> > # xfs_repair -n /dev/sda
> > Phase 1 - find and verify superblock...
> >         - reporting progress in intervals of 15 minutes
> > Phase 2 - using internal log
> >         - zero log...
> >         - 16:30:50: zeroing log - 16320 of 16320 blocks done
> >         - scan filesystem freespace and inode maps...
> > agf_freeblks 25, counted 0 in ag 4
> > sb_fdblocks 8823, counted 8798
> > 
> > The root cause of this problem is the numrecs handling in
> > xfs_freesp_init_recs, which is used to initialize a new AG.  Prior to
> > calling the function, we set up the new bnobt block with numrecs == 1
> > and rely on _freesp_init_recs to format that new record.  If the last
> > record created has a blockcount of zero, then it sets numrecs = 0.
> > 
> > That last bit isn't correct if the AG contains the log, the start of the
> > log is not immediately after the initial blocks due to stripe alignment,
> > and the end of the log is perfectly aligned with the end of the AG.  For
> > this case, we actually formatted a single bnobt record to handle the
> > free space before the start of the (stripe aligned) log, and incremented
> > arec to try to format a second record.  That second record turned out to
> > be unnecessary, so what we really want is to leave numrecs at 1.
> > 
> > The numrecs handling itself is overly complicated because a different
> > function sets numrecs == 1.  Change the bnobt creation code to start
> > with numrecs set to zero and only increment it after successfully
> > formatting a free space extent into the btree block.
> > 
> > Fixes: f327a00745ff ("xfs: account for log space when formatting new AGs")
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> >  fs/xfs/libxfs/xfs_ag.c |   10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > 
> > diff --git a/fs/xfs/libxfs/xfs_ag.c b/fs/xfs/libxfs/xfs_ag.c
> > index 1b078bbbf225..4481ce8ead9d 100644
> > --- a/fs/xfs/libxfs/xfs_ag.c
> > +++ b/fs/xfs/libxfs/xfs_ag.c
> > @@ -499,6 +499,7 @@ xfs_freesp_init_recs(
> >  			 */
> >  			arec->ar_blockcount = cpu_to_be32(start -
> >  						mp->m_ag_prealloc_blocks);
> > +			be16_add_cpu(&block->bb_numrecs, 1);
> >  			nrec = arec + 1;
> >  
> >  			/*
> > @@ -509,7 +510,6 @@ xfs_freesp_init_recs(
> >  					be32_to_cpu(arec->ar_startblock) +
> >  					be32_to_cpu(arec->ar_blockcount));
> >  			arec = nrec;
> > -			be16_add_cpu(&block->bb_numrecs, 1);
> >  		}
> >  		/*
> >  		 * Change record start to after the internal log
> > @@ -525,8 +525,8 @@ xfs_freesp_init_recs(
> >  	 */
> >  	arec->ar_blockcount = cpu_to_be32(id->agsize -
> >  					  be32_to_cpu(arec->ar_startblock));
> > -	if (!arec->ar_blockcount)
> > -		block->bb_numrecs = 0;
> > +	if (arec->ar_blockcount)
> > +		be16_add_cpu(&block->bb_numrecs, 1);
> 
> Ok, but I think the comment above this about resetting the count
> back to zero needs to be updated as we aren't resetting anything
> back to zero anymore.

Done:

	/*
	 * Calculate the block count of this record; if it is nonzero,
	 * increment the record count.
	 */

--D

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

  reply	other threads:[~2023-04-28  4:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-27 22:48 [PATCHSET 0/4] xfs: bug fixes for 6.4-rc1 Darrick J. Wong
2023-04-27 22:48 ` [PATCH 1/4] xfs: don't unconditionally null args->pag in xfs_bmap_btalloc_at_eof Darrick J. Wong
2023-04-28  1:49   ` Dave Chinner
2023-04-28  4:30     ` Darrick J. Wong
2023-04-27 22:49 ` [PATCH 2/4] xfs: set bnobt/cntbt numrecs correctly when formatting new AGs Darrick J. Wong
2023-04-28  2:11   ` Dave Chinner
2023-04-28  4:29     ` Darrick J. Wong [this message]
2023-04-27 22:49 ` [PATCH 3/4] xfs: flush dirty data and drain directios before scrubbing cow fork Darrick J. Wong
2023-04-28  2:11   ` Dave Chinner
2023-04-27 22:49 ` [PATCH 4/4] xfs: don't allocate into the data fork for an unshare request Darrick J. Wong
2023-04-28  2:13   ` Dave Chinner
2023-04-28  2:20     ` Darrick J. Wong
2023-04-28  2:31       ` Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
2023-05-01 18:26 [PATCHSET v2 0/4] xfs: bug fixes for 6.4-rc1 Darrick J. Wong
2023-05-01 18:27 ` [PATCH 2/4] xfs: set bnobt/cntbt numrecs correctly when formatting new AGs Darrick J. Wong
2023-05-01 23:05   ` 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=20230428042905.GJ59213@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=david@fromorbit.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).