All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Gao Xiang <hsiangkao@redhat.com>
Cc: linux-xfs@vger.kernel.org, "Darrick J. Wong" <djwong@kernel.org>,
	Dave Chinner <dchinner@redhat.com>, Zorro Lang <zlang@redhat.com>
Subject: Re: [PATCH] xfs: update superblock counters correctly for !lazysbcount
Date: Tue, 27 Apr 2021 10:25:31 -0400	[thread overview]
Message-ID: <YIge2/FRLy4Xjvcp@bfoster> (raw)
In-Reply-To: <20210427131318.GA103178@xiangao.remote.csb>

On Tue, Apr 27, 2021 at 09:13:18PM +0800, Gao Xiang wrote:
> On Tue, Apr 27, 2021 at 08:46:25AM -0400, Brian Foster wrote:
> > On Tue, Apr 27, 2021 at 09:12:01AM +0800, Gao Xiang wrote:
> > > From: Dave Chinner <dchinner@redhat.com>
> > > 
> > > Keep the mount superblock counters up to date for !lazysbcount
> > > filesystems so that when we log the superblock they do not need
> > > updating in any way because they are already correct.
> > > 
> > > It's found by what Zorro reported:
> > > 1. mkfs.xfs -f -l lazy-count=0 -m crc=0 $dev
> > > 2. mount $dev $mnt
> > > 3. fsstress -d $mnt -p 100 -n 1000 (maybe need more or less io load)
> > > 4. umount $mnt
> > > 5. xfs_repair -n $dev
> > > and I've seen no problem with this patch.
> > > 
> > > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > > Reported-by: Zorro Lang <zlang@redhat.com>
> > > Reviewed-by: Gao Xiang <hsiangkao@redhat.com>
> > > Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
> > > ---
> > 
> > Could you provide a bit more detail on the problem in the commit log?
> > From the description and code change, it seems like there is some
> > problem with doing the percpu aggregation in xfs_log_sb() on
> > !lazysbcount filesystems. Therefore this patch reserves that behavior
> > for lazysbcount, and instead enables per-transaction updates in the
> > !lazysbcount specific cleanup path. Am I following that correctly?
> 
> This patch inherited from Dave's patch [1] (and I added reproduable
> steps),
> https://lore.kernel.org/r/20210422014446.GZ63242@dread.disaster.area
> 
> More details see my original patch v2:
> https://lore.kernel.org/r/20210420110855.2961626-1-hsiangkao@redhat.com
> 

Ok, thanks. So the bit about xfs_log_sb() is to avoid an incorrect
overwrite of the in-core sb counters from the percpu counters on
!lazysbcount. The xfs_trans_apply_sb_deltas() function already applies
the transaction deltas to the on-disk superblock buffer, so the change
to xfs_trans_unreserve_and_mod_sb() is basically to apply those same
deltas to the in-core superblock so they are consistent in the
!lazysbcount case... yes? If I'm following that correctly, this looks
good to me:

Reviewed-by: Brian Foster <bfoster@redhat.com>

> Thanks,
> Gao Xiang
> 
> > 
> > Brian
> > 
> > > 
> > > As per discussion earilier [1], use the way Dave suggested instead.
> > > Also update the line to
> > > 	mp->m_sb.sb_fdblocks += tp->t_fdblocks_delta + tp->t_res_fdblocks_delta;
> > > so it can fix the case above.
> > > 
> > > with XFS debug off, xfstests auto testcases fail on my loop-device-based
> > > testbed with this patch and Darrick's [2]:
> > > 
> > > generic/095 generic/300 generic/600 generic/607 xfs/073 xfs/148 xfs/273
> > > xfs/293 xfs/491 xfs/492 xfs/495 xfs/503 xfs/505 xfs/506 xfs/514 xfs/515
> > > 
> > > MKFS_OPTIONS="-mcrc=0 -llazy-count=0"
> > > 
> > > and these testcases above still fail without these patches or with
> > > XFS debug on, so I've seen no regression due to this patch.
> > > 
> > > [1] https://lore.kernel.org/r/20210422030102.GA63242@dread.disaster.area/
> > > [2] https://lore.kernel.org/r/20210425154634.GZ3122264@magnolia/
> > > 
> > >  fs/xfs/libxfs/xfs_sb.c | 16 +++++++++++++---
> > >  fs/xfs/xfs_trans.c     |  3 +++
> > >  2 files changed, 16 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c
> > > index 60e6d255e5e2..dfbbcbd448c1 100644
> > > --- a/fs/xfs/libxfs/xfs_sb.c
> > > +++ b/fs/xfs/libxfs/xfs_sb.c
> > > @@ -926,9 +926,19 @@ xfs_log_sb(
> > >  	struct xfs_mount	*mp = tp->t_mountp;
> > >  	struct xfs_buf		*bp = xfs_trans_getsb(tp);
> > >  
> > > -	mp->m_sb.sb_icount = percpu_counter_sum(&mp->m_icount);
> > > -	mp->m_sb.sb_ifree = percpu_counter_sum(&mp->m_ifree);
> > > -	mp->m_sb.sb_fdblocks = percpu_counter_sum(&mp->m_fdblocks);
> > > +	/*
> > > +	 * Lazy sb counters don't update the in-core superblock so do that now.
> > > +	 * If this is at unmount, the counters will be exactly correct, but at
> > > +	 * any other time they will only be ballpark correct because of
> > > +	 * reservations that have been taken out percpu counters. If we have an
> > > +	 * unclean shutdown, this will be corrected by log recovery rebuilding
> > > +	 * the counters from the AGF block counts.
> > > +	 */
> > > +	if (xfs_sb_version_haslazysbcount(&mp->m_sb)) {
> > > +		mp->m_sb.sb_icount = percpu_counter_sum(&mp->m_icount);
> > > +		mp->m_sb.sb_ifree = percpu_counter_sum(&mp->m_ifree);
> > > +		mp->m_sb.sb_fdblocks = percpu_counter_sum(&mp->m_fdblocks);
> > > +	}
> > >  
> > >  	xfs_sb_to_disk(bp->b_addr, &mp->m_sb);
> > >  	xfs_trans_buf_set_type(tp, bp, XFS_BLFT_SB_BUF);
> > > diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c
> > > index bcc978011869..1e37aa8eca5a 100644
> > > --- a/fs/xfs/xfs_trans.c
> > > +++ b/fs/xfs/xfs_trans.c
> > > @@ -629,6 +629,9 @@ xfs_trans_unreserve_and_mod_sb(
> > >  
> > >  	/* apply remaining deltas */
> > >  	spin_lock(&mp->m_sb_lock);
> > > +	mp->m_sb.sb_fdblocks += tp->t_fdblocks_delta + tp->t_res_fdblocks_delta;
> > > +	mp->m_sb.sb_icount += idelta;
> > > +	mp->m_sb.sb_ifree += ifreedelta;
> > >  	mp->m_sb.sb_frextents += rtxdelta;
> > >  	mp->m_sb.sb_dblocks += tp->t_dblocks_delta;
> > >  	mp->m_sb.sb_agcount += tp->t_agcount_delta;
> > > -- 
> > > 2.27.0
> > > 
> > 
> 


  reply	other threads:[~2021-04-27 14:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27  1:12 [PATCH] xfs: update superblock counters correctly for !lazysbcount Gao Xiang
2021-04-27  3:07 ` Darrick J. Wong
2021-04-27  3:15   ` Gao Xiang
2021-04-28  7:49   ` Zorro Lang
2021-04-27 12:46 ` Brian Foster
2021-04-27 13:13   ` Gao Xiang
2021-04-27 14:25     ` Brian Foster [this message]
2021-04-27 14:30       ` Gao Xiang

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=YIge2/FRLy4Xjvcp@bfoster \
    --to=bfoster@redhat.com \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hsiangkao@redhat.com \
    --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.