From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/9] xfs_repair: create a new class of btree rebuild cursors
Date: Fri, 29 May 2020 14:08:32 -0700 [thread overview]
Message-ID: <20200529210832.GS8230@magnolia> (raw)
In-Reply-To: <20200528150921.GB17794@bfoster>
On Thu, May 28, 2020 at 11:09:21AM -0400, Brian Foster wrote:
> On Wed, May 27, 2020 at 03:07:33PM -0700, Darrick J. Wong wrote:
> > On Wed, May 27, 2020 at 08:18:04AM -0400, Brian Foster wrote:
> > > On Tue, May 19, 2020 at 06:51:02PM -0700, Darrick J. Wong wrote:
> > > > From: Darrick J. Wong <darrick.wong@oracle.com>
> > > >
> > > > Create some new support structures and functions to assist phase5 in
> > > > using the btree bulk loader to reconstruct metadata btrees. This is the
> > > > first step in removing the open-coded rebuilding code.
> > > >
> > > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > > > ---
> > > > repair/phase5.c | 239 ++++++++++++++++++++++++++++++++++++++++++++++++++-----
> > > > 1 file changed, 218 insertions(+), 21 deletions(-)
> > > >
> > > >
> > > > diff --git a/repair/phase5.c b/repair/phase5.c
> > > > index 84c05a13..8f5e5f59 100644
> > > > --- a/repair/phase5.c
> > > > +++ b/repair/phase5.c
> > > > @@ -18,6 +18,7 @@
> > > > #include "progress.h"
> > > > #include "slab.h"
> > > > #include "rmap.h"
> > > > +#include "bload.h"
> > > >
> > > > /*
> > > > * we maintain the current slice (path from root to leaf)
> > > ...
> > > > @@ -306,6 +324,156 @@ _("error - not enough free space in filesystem\n"));
> > > > #endif
> > > > }
> > > >
> > > ...
> > > > +static void
> > > > +consume_freespace(
> > > > + xfs_agnumber_t agno,
> > > > + struct extent_tree_node *ext_ptr,
> > > > + uint32_t len)
> > > > +{
> > > > + struct extent_tree_node *bno_ext_ptr;
> > > > + xfs_agblock_t new_start = ext_ptr->ex_startblock + len;
> > > > + xfs_extlen_t new_len = ext_ptr->ex_blockcount - len;
> > > > +
> > > > + /* Delete the used-up extent from both extent trees. */
> > > > +#ifdef XR_BLD_FREE_TRACE
> > > > + fprintf(stderr, "releasing extent: %u [%u %u]\n", agno,
> > > > + ext_ptr->ex_startblock, ext_ptr->ex_blockcount);
> > > > +#endif
> > > > + bno_ext_ptr = find_bno_extent(agno, ext_ptr->ex_startblock);
> > > > + ASSERT(bno_ext_ptr != NULL);
> > > > + get_bno_extent(agno, bno_ext_ptr);
> > > > + release_extent_tree_node(bno_ext_ptr);
> > > > +
> > > > + ext_ptr = get_bcnt_extent(agno, ext_ptr->ex_startblock,
> > > > + ext_ptr->ex_blockcount);
> > > > + release_extent_tree_node(ext_ptr);
> > > > +
> > >
> > > Not having looked too deeply at the in-core extent tracking structures,
> > > is there any particular reason we unconditionally remove and reinsert
> > > new records each time around? Is it because we're basically changing the
> > > extent index in the tree? If so, comment please (an update to the
> > > comment below is probably fine). :)
> >
> > Yes. We're changing the free space tree records, and the incore bno and
> > cnt trees maintain the records in sorted order. Therefore, if we want
> > to change a record we have to delete the record from the tree and
> > reinsert it.
> >
> > > > + /*
> > > > + * If we only used part of this last extent, then we must reinsert the
> > > > + * extent in the extent trees.
> >
> > /*
> > * If we only used part of this last extent, then we must reinsert the
> > * extent to maintain proper sorting order.
> > */
> >
> > How about that?
> >
>
> Works for me, thanks.
>
> > > > + */
> > > > + if (new_len > 0) {
> > > > + add_bno_extent(agno, new_start, new_len);
> > > > + add_bcnt_extent(agno, new_start, new_len);
> > > > + }
> > > > +}
> > > > +
> > > > +/* Reserve blocks for the new btree. */
> > > > +static void
> > > > +setup_rebuild(
> > > > + struct xfs_mount *mp,
> > > > + xfs_agnumber_t agno,
> > > > + struct bt_rebuild *btr,
> > > > + uint32_t nr_blocks)
> > > > +{
> > > > + struct extent_tree_node *ext_ptr;
> > > > + uint32_t blocks_allocated = 0;
> > > > + uint32_t len;
> > > > + int error;
> > > > +
> > > > + while (blocks_allocated < nr_blocks) {
> > > > + /*
> > > > + * Grab the smallest extent and use it up, then get the
> > > > + * next smallest. This mimics the init_*_cursor code.
> > > > + */
> > > > + ext_ptr = findfirst_bcnt_extent(agno);
> > >
> > > Extra whitespace ^
> > >
> > > > + if (!ext_ptr)
> > > > + do_error(
> > > > +_("error - not enough free space in filesystem\n"));
> > > > +
> > > > + /* Use up the extent we've got. */
> > > > + len = min(ext_ptr->ex_blockcount, nr_blocks - blocks_allocated);
> > > > + error = xrep_newbt_add_blocks(&btr->newbt,
> > > > + XFS_AGB_TO_FSB(mp, agno,
> > > > + ext_ptr->ex_startblock),
> > > > + len);
> > >
> > > Alignment.
> >
> > Will fix both of these.
> >
> > > > + if (error)
> > > > + do_error(_("could not set up btree reservation: %s\n"),
> > > > + strerror(-error));
> > > > +
> > > > + error = rmap_add_ag_rec(mp, agno, ext_ptr->ex_startblock, len,
> > > > + btr->newbt.oinfo.oi_owner);
> > > > + if (error)
> > > > + do_error(_("could not set up btree rmaps: %s\n"),
> > > > + strerror(-error));
> > > > +
> > > > + consume_freespace(agno, ext_ptr, len);
> > > > + blocks_allocated += len;
> > > > + }
> > > > +#ifdef XR_BLD_FREE_TRACE
> > > > + fprintf(stderr, "blocks_allocated = %d\n",
> > > > + blocks_allocated);
> > > > +#endif
> > > > +}
> > > > +
> > > > +/* Feed one of the new btree blocks to the bulk loader. */
> > > > +static int
> > > > +rebuild_claim_block(
> > > > + struct xfs_btree_cur *cur,
> > > > + union xfs_btree_ptr *ptr,
> > > > + void *priv)
> > > > +{
> > > > + struct bt_rebuild *btr = priv;
> > > > +
> > > > + return xrep_newbt_claim_block(cur, &btr->newbt, ptr);
> > > > +}
> > > > +
> > >
> > > Seems like an unnecessary helper, unless this grows more code in later
> > > patches..?
> >
> > It doesn't grow any more code, but keep in mind that get_record,
> > claim_block, and iroot_size are all callbacks of xfs_btree_bload(). The
> > priv parameter passed to that function are passed unchanged to the three
> > callbacks. The bulk load code doesn't know anything about where the
> > blocks or the records come from, so this is how both repairs will pass
> > that information to the callbacks.
> >
>
> Ok.
>
> > > > static void
> > > > write_cursor(bt_status_t *curs)
> > > > {
> > > ...
> > > > @@ -2287,28 +2483,29 @@ keep_fsinos(xfs_mount_t *mp)
> > > >
> > > > static void
> > > > phase5_func(
> > > > - xfs_mount_t *mp,
> > > > - xfs_agnumber_t agno,
> > > > - struct xfs_slab *lost_fsb)
> > > > + struct xfs_mount *mp,
> > > > + xfs_agnumber_t agno,
> > > > + struct xfs_slab *lost_fsb)
> > > > {
> > > > - uint64_t num_inos;
> > > > - uint64_t num_free_inos;
> > > > - uint64_t finobt_num_inos;
> > > > - uint64_t finobt_num_free_inos;
> > > > - bt_status_t bno_btree_curs;
> > > > - bt_status_t bcnt_btree_curs;
> > > > - bt_status_t ino_btree_curs;
> > > > - bt_status_t fino_btree_curs;
> > > > - bt_status_t rmap_btree_curs;
> > > > - bt_status_t refcnt_btree_curs;
> > > > - int extra_blocks = 0;
> > > > - uint num_freeblocks;
> > > > - xfs_extlen_t freeblks1;
> > > > + struct repair_ctx sc = { .mp = mp, };
> > >
> > > I don't see any reason to add sc here when it's still unused. It's not
> > > as if a single variable is saving complexity somewhere else. I guess
> > > I'll defer to Eric on the approach wrt to the other unused warnings.
> >
> > <shrug> I'll ask. It seems dumb to have a prep patch that adds a bunch
> > of symbols that won't get used until the next patch, but OTOH combining
> > the two will make for a ~40K patch.
> >
>
> I've no strong preference either way in general (the single variable
> thing aside) as long as each patch compiles and functions correctly and
> warnings are addressed by the end of the series. I do think that if we
> keep separate patches, it should probably be documented in the commit
> log that unused infrastructure is introduced (i.e. warnings expected)
> and users are introduced in a following patch. It's usually easier to
> squash patches than separate, so the maintainer can always squash them
> post review if he wanted to eliminate the warnings from the commit
> history.
Ok, will do.
--D
> Brian
>
> > > Also, what's the purpose of the rmap change below? I'm wondering if that
> > > (along with all of the indentation cleanup) should be its own patch with
> > > appropriate explanation.
> >
> > Errk, that one definitely should be separate.
> >
> > > Brian
> > >
> > > > + struct agi_stat agi_stat = {0,};
> > > > + uint64_t num_inos;
> > > > + uint64_t num_free_inos;
> > > > + uint64_t finobt_num_inos;
> > > > + uint64_t finobt_num_free_inos;
> > > > + bt_status_t bno_btree_curs;
> > > > + bt_status_t bcnt_btree_curs;
> > > > + bt_status_t ino_btree_curs;
> > > > + bt_status_t fino_btree_curs;
> > > > + bt_status_t rmap_btree_curs;
> > > > + bt_status_t refcnt_btree_curs;
> > > > + int extra_blocks = 0;
> > > > + uint num_freeblocks;
> > > > + xfs_extlen_t freeblks1;
> > > > #ifdef DEBUG
> > > > - xfs_extlen_t freeblks2;
> > > > + xfs_extlen_t freeblks2;
> > > > #endif
> > > > - xfs_agblock_t num_extents;
> > > > - struct agi_stat agi_stat = {0,};
> > > > + xfs_agblock_t num_extents;
> > > >
> > > > if (verbose)
> > > > do_log(_(" - agno = %d\n"), agno);
> > > > @@ -2516,8 +2713,8 @@ inject_lost_blocks(
> > > > if (error)
> > > > goto out_cancel;
> > > >
> > > > - error = -libxfs_free_extent(tp, *fsb, 1, &XFS_RMAP_OINFO_AG,
> > > > - XFS_AG_RESV_NONE);
> > > > + error = -libxfs_free_extent(tp, *fsb, 1,
> > > > + &XFS_RMAP_OINFO_ANY_OWNER, XFS_AG_RESV_NONE);
> > > > if (error)
> > > > goto out_cancel;
> > > >
> > > >
> > >
> >
>
next prev parent reply other threads:[~2020-05-29 21:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-20 1:50 [PATCH v5 0/9] xfs_repair: use btree bulk loading Darrick J. Wong
2020-05-20 1:50 ` [PATCH 1/9] xfs_repair: port the online repair newbt structure Darrick J. Wong
2020-05-27 12:15 ` Brian Foster
2020-05-27 22:34 ` Darrick J. Wong
2020-05-28 15:08 ` Brian Foster
2020-05-29 21:01 ` Darrick J. Wong
2020-06-01 12:03 ` Brian Foster
2020-06-02 0:12 ` Darrick J. Wong
2020-05-20 1:50 ` [PATCH 2/9] xfs_repair: remove gratuitous code block in phase5 Darrick J. Wong
2020-05-27 12:15 ` Brian Foster
2020-05-20 1:51 ` [PATCH 3/9] xfs_repair: create a new class of btree rebuild cursors Darrick J. Wong
2020-05-27 12:18 ` Brian Foster
2020-05-27 22:07 ` Darrick J. Wong
2020-05-28 15:09 ` Brian Foster
2020-05-29 21:08 ` Darrick J. Wong [this message]
2020-05-20 1:51 ` [PATCH 4/9] xfs_repair: rebuild free space btrees with bulk loader Darrick J. Wong
2020-05-28 15:10 ` Brian Foster
2020-05-29 21:39 ` Darrick J. Wong
2020-06-01 12:05 ` Brian Foster
2020-06-02 0:21 ` Darrick J. Wong
2020-05-20 1:51 ` [PATCH 5/9] xfs_repair: rebuild inode " Darrick J. Wong
2020-05-28 15:11 ` Brian Foster
2020-05-29 22:18 ` Darrick J. Wong
2020-05-29 22:32 ` Darrick J. Wong
2020-05-20 1:51 ` [PATCH 6/9] xfs_repair: rebuild reverse mapping " Darrick J. Wong
2020-05-20 1:51 ` [PATCH 7/9] xfs_repair: rebuild refcount " Darrick J. Wong
2020-05-20 1:51 ` [PATCH 8/9] xfs_repair: remove old btree rebuild support code Darrick J. Wong
2020-05-20 1:51 ` [PATCH 9/9] xfs_repair: track blocks lost during btree construction via extents Darrick J. Wong
2020-05-28 17:00 ` Brian Foster
2020-05-29 22:19 ` Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2020-05-09 16:31 [PATCH v4 0/9] xfs_repair: use btree bulk loading Darrick J. Wong
2020-05-09 16:31 ` [PATCH 3/9] xfs_repair: create a new class of btree rebuild cursors Darrick J. Wong
2020-05-14 15:11 ` Brian Foster
2020-05-14 19:47 ` Darrick J. Wong
2020-03-04 3:29 [PATCH v3 0/9] xfs_repair: use btree bulk loading Darrick J. Wong
2020-03-04 3:29 ` [PATCH 3/9] xfs_repair: create a new class of btree rebuild cursors Darrick J. Wong
2020-01-01 1:21 [PATCH v2 0/9] xfs_repair: use btree bulk loading Darrick J. Wong
2020-01-01 1:21 ` [PATCH 3/9] xfs_repair: create a new class of btree rebuild cursors Darrick J. Wong
2019-10-29 23:45 [PATCH RFC 0/9] xfs_repair: use btree bulk loading Darrick J. Wong
2019-10-29 23:45 ` [PATCH 3/9] xfs_repair: create a new class of btree rebuild cursors 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=20200529210832.GS8230@magnolia \
--to=darrick.wong@oracle.com \
--cc=bfoster@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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).