All of lore.kernel.org
 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] xfs: stabilize fs summary counters for online fsck
Date: Thu, 3 Aug 2023 07:55:57 -0700	[thread overview]
Message-ID: <20230803145557.GF11352@frogsfrogsfrogs> (raw)
In-Reply-To: <ZMtKiMSVOtk7CbmL@dread.disaster.area>

On Thu, Aug 03, 2023 at 04:34:48PM +1000, Dave Chinner wrote:
> On Wed, Aug 02, 2023 at 10:22:18PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > If the fscounters scrubber notices incorrect summary counters, it's
> > entirely possible that scrub is simply racing with other threads that
> > are updating the incore counters.  There isn't a good way to stabilize
> > percpu counters or set ourselves up to observe live updates with hooks
> > like we do for the quotacheck or nlinks scanners, so we instead choose
> > to freeze the filesystem long enough to walk the incore per-AG
> > structures.
> > 
> > Past me thought that it was going to be commonplace to have to freeze
> > the filesystem to perform some kind of repair and set up a whole
> > separate infrastructure to freeze the filesystem in such a way that
> > userspace could not unfreeze while we were running.  This involved
> > adding a mutex and freeze_super/thaw_super functions and dealing with
> > the fact that the VFS freeze/thaw functions can free the VFS superblock
> > references on return.
> > 
> > This was all very overwrought, since fscounters turned out to be the
> > only user of scrub freezes, and it doesn't require the log to quiesce,
> > only the incore superblock counters.  We prevent other threads from
> > changing the freeze level by calling freeze_super_excl with a custom
> > freeze cookie to keep everyone else out of the filesystem.
> > 
> > The end result is that fscounters should be much more efficient.  When
> > we're checking a busy system and we can't stabilize the counters, the
> > custom freeze will do less work, which should result in less downtime.
> > Repair should be similarly speedy, but that's in the next patch.
> > 
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> >  fs/xfs/scrub/fscounters.c |  198 ++++++++++++++++++++++++++++++++++-----------
> >  fs/xfs/scrub/fscounters.h |   20 +++++
> >  fs/xfs/scrub/scrub.c      |    6 +
> >  fs/xfs/scrub/scrub.h      |    1 
> >  fs/xfs/scrub/trace.h      |   26 ++++++
> >  5 files changed, 203 insertions(+), 48 deletions(-)
> >  create mode 100644 fs/xfs/scrub/fscounters.h
> 
> Code changes look ok, though I am wondering why struct
> xchk_fscounters needs to be moved to it's own header file? AFAICT it
> is still only used by fs/xfs/scrub/fscounters.c, so I'm not sure
> what purpose the new header file serves....

The header file is the basis for the repair patch which I've previously
sent to the list.
https://lore.kernel.org/linux-xfs/168506061531.3732954.7713322896089390150.stgit@frogsfrogsfrogs/

It's not strictly needed at this time.  I'll resend without that bit.

--D

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

      reply	other threads:[~2023-08-03 14:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-03  5:22 [PATCH] xfs: stabilize fs summary counters for online fsck Darrick J. Wong
2023-08-03  6:34 ` Dave Chinner
2023-08-03 14:55   ` Darrick J. Wong [this message]

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=20230803145557.GF11352@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 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.