public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 03/14] xfs: repair free space btrees
Date: Wed, 6 Jun 2018 13:34:38 +1000	[thread overview]
Message-ID: <20180606033438.GN10363@dastard> (raw)
In-Reply-To: <20180606015026.GQ9437@magnolia>

On Tue, Jun 05, 2018 at 06:50:26PM -0700, Darrick J. Wong wrote:
> On Mon, Jun 04, 2018 at 12:12:34PM +1000, Dave Chinner wrote:
> > On Wed, May 30, 2018 at 12:30:58PM -0700, Darrick J. Wong wrote:
> > > +
> > > +/* Free space btree repair. */
> > 
> > Can you add a decription of the algorithm used here.
> 
> Ok.
> 
> /*
>  * Free Space Btree Repair
>  * =======================
>  *
>  * The reverse mappings are supposed to record all space usage for the
>  * entire AG.  Therefore, we can recalculate the free extents in an AG
>  * by looking for gaps in the physical extents recorded in the rmapbt.
>  * On a reflink filesystem this is a little more tricky in that we have
>  * to be aware that the rmap records are allowed to overlap.
>  *
>  * We derive which blocks belonged to the old bnobt/cntbt by recording
>  * all the OWN_AG extents and subtracting out the blocks owned by all
>  * other OWN_AG metadata: the rmapbt blocks visited while iterating the
>  * reverse mappings and the AGFL blocks.
>  *
>  * Once we have both of those pieces, we can reconstruct the bnobt and
>  * cntbt by blowing out the free block state and freeing all the extents
>  * that we found.  This adds the requirement that we can't have any busy
>  * extents in the AG because the busy code cannot handle duplicate
>  * records.
>  *
>  * Note that we can only rebuild both free space btrees at the same
>  * time.

Ok, so if I've got this right, the limitations indicated in the last
two paragraphs are a result of makring space free by calling
xfs_free_extent() on all the extents in the list? If so, can you
mention that this is an implementation artifact, not a algorithmic
limitation?

> > > +/* Allocate a block from the (cached) longest extent in the AG. */
> > > +STATIC xfs_fsblock_t
> > > +xfs_repair_allocbt_alloc_from_longest(
> > > +	struct xfs_repair_alloc		*ra,
> > > +	struct xfs_repair_alloc_extent	**longest)
> > > +{
> > > +	xfs_fsblock_t			fsb;
> > > +
> > > +	if (*longest && (*longest)->len == 0) {
> > > +		list_del(&(*longest)->list);
> > > +		kmem_free(*longest);
> > > +		*longest = NULL;
> > > +	}
> > > +
> > > +	if (*longest == NULL) {
> > > +		*longest = xfs_repair_allocbt_get_longest(ra);
> > > +		if (*longest == NULL)
> > > +			return NULLFSBLOCK;
> > > +	}
> > > +
> > > +	fsb = XFS_AGB_TO_FSB(ra->sc->mp, ra->sc->sa.agno, (*longest)->bno);
> > > +	(*longest)->bno++;
> > > +	(*longest)->len--;
> > 
> > What if this makes the longest extent no longer the longest on the
> > extent list?
> 
> It should be fine, since all we do later is zero out the free space
> counters in the AG and start freeing extents.  The regular extent
> freeing code takes care to update the agf/perag longest-free counter
> appropriately.

Comment, please. :P

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-06-06  3:34 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-30 19:30 [PATCH v15.2 00/14] xfs-4.18: online repair support Darrick J. Wong
2018-05-30 19:30 ` [PATCH 01/14] xfs: repair the AGF and AGFL Darrick J. Wong
2018-06-04  1:52   ` Dave Chinner
2018-06-05 23:18     ` Darrick J. Wong
2018-06-06  4:06       ` Dave Chinner
2018-06-06  4:56         ` Darrick J. Wong
2018-06-07  0:31           ` Dave Chinner
2018-06-07  4:42             ` Darrick J. Wong
2018-06-08  0:55               ` Dave Chinner
2018-06-08  1:23                 ` Darrick J. Wong
2018-05-30 19:30 ` [PATCH 02/14] xfs: repair the AGI Darrick J. Wong
2018-06-04  1:56   ` Dave Chinner
2018-06-05 23:54     ` Darrick J. Wong
2018-05-30 19:30 ` [PATCH 03/14] xfs: repair free space btrees Darrick J. Wong
2018-06-04  2:12   ` Dave Chinner
2018-06-06  1:50     ` Darrick J. Wong
2018-06-06  3:34       ` Dave Chinner [this message]
2018-06-06  4:01         ` Darrick J. Wong
2018-05-30 19:31 ` [PATCH 04/14] xfs: repair inode btrees Darrick J. Wong
2018-06-04  3:41   ` Dave Chinner
2018-06-06  3:55     ` Darrick J. Wong
2018-06-06  4:32       ` Dave Chinner
2018-06-06  4:58         ` Darrick J. Wong
2018-05-30 19:31 ` [PATCH 05/14] xfs: repair the rmapbt Darrick J. Wong
2018-05-31  5:42   ` Amir Goldstein
2018-06-06 21:13     ` Darrick J. Wong
2018-05-30 19:31 ` [PATCH 06/14] xfs: repair refcount btrees Darrick J. Wong
2018-05-30 19:31 ` [PATCH 07/14] xfs: repair inode records Darrick J. Wong
2018-05-30 19:31 ` [PATCH 08/14] xfs: zap broken inode forks Darrick J. Wong
2018-05-30 19:31 ` [PATCH 09/14] xfs: repair inode block maps Darrick J. Wong
2018-05-30 19:31 ` [PATCH 10/14] xfs: repair damaged symlinks Darrick J. Wong
2018-05-30 19:31 ` [PATCH 11/14] xfs: repair extended attributes Darrick J. Wong
2018-05-30 19:31 ` [PATCH 12/14] xfs: scrub should set preen if attr leaf has holes Darrick J. Wong
2018-05-30 19:32 ` [PATCH 13/14] xfs: repair quotas Darrick J. Wong
2018-05-30 19:32 ` [PATCH 14/14] xfs: implement live quotacheck as part of quota repair Darrick J. Wong

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=20180606033438.GN10363@dastard \
    --to=david@fromorbit.com \
    --cc=darrick.wong@oracle.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