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 1/9] xfs_repair: port the online repair newbt structure
Date: Thu, 14 May 2020 12:20:37 -0700 [thread overview]
Message-ID: <20200514192037.GD6714@magnolia> (raw)
In-Reply-To: <20200514150933.GA50849@bfoster>
On Thu, May 14, 2020 at 11:09:33AM -0400, Brian Foster wrote:
> On Sat, May 09, 2020 at 09:31:47AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> >
> > Port the new btree staging context and related block reservation helper
> > code from the kernel to repair. We'll use this in subsequent patches to
> > implement btree bulk loading.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> > include/libxfs.h | 1
> > libxfs/libxfs_api_defs.h | 2
> > repair/Makefile | 4 -
> > repair/bload.c | 276 ++++++++++++++++++++++++++++++++++++++++++++++
> > repair/bload.h | 79 +++++++++++++
> > repair/xfs_repair.c | 17 +++
> > 6 files changed, 377 insertions(+), 2 deletions(-)
> > create mode 100644 repair/bload.c
> > create mode 100644 repair/bload.h
> >
> >
> ...
> > diff --git a/repair/bload.c b/repair/bload.c
> > new file mode 100644
> > index 00000000..ab05815c
> > --- /dev/null
> > +++ b/repair/bload.c
> > @@ -0,0 +1,276 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2020 Oracle. All Rights Reserved.
> > + * Author: Darrick J. Wong <darrick.wong@oracle.com>
> > + */
> > +#include <libxfs.h>
> > +#include "bload.h"
> > +
> > +#define trace_xrep_newbt_claim_block(...) ((void) 0)
> > +#define trace_xrep_newbt_reserve_space(...) ((void) 0)
> > +#define trace_xrep_newbt_unreserve_space(...) ((void) 0)
> > +#define trace_xrep_newbt_claim_block(...) ((void) 0)
> > +
> > +int bload_leaf_slack = -1;
> > +int bload_node_slack = -1;
> > +
> > +/* Ported routines from fs/xfs/scrub/repair.c */
> > +
>
> Any plans to generalize/lift more of this stuff into libxfs if it's
> going to be shared with xfsprogs?
That depends on what the final online repair code looks like.
I suspect it'll be different enough that it's not worth sharing, but I
wouldn't be opposed to sharing identical functions.
> ...
> > +/* Free all the accounting infor and disk space we reserved for a new btree. */
> > +void
> > +xrep_newbt_destroy(
> > + struct xrep_newbt *xnr,
> > + int error)
> > +{
> > + struct repair_ctx *sc = xnr->sc;
> > + struct xrep_newbt_resv *resv, *n;
> > +
> > + if (error)
> > + goto junkit;
>
> Could use a comment on why we skip block freeing here..
I wonder what was the original reason for that?
IIRC if we actually error out of btree rebuilds then we've done
something totally wrong while setting up the btree loader, or the
storage is so broken that writes failed. Repair is just going to call
do_error() to terminate (and leave us with a broken filesystem) so we
could just terminate right there at the top.
> I'm also wondering if we can check error in the primary loop and kill
> the label and duplicate loop, but I guess that depends on whether the
> fields are always valid.
I think they are.
> > +
> > + list_for_each_entry_safe(resv, n, &xnr->reservations, list) {
> > + /* We don't have EFIs here so skip the EFD. */
> > +
> > + /* Free every block we didn't use. */
> > + resv->fsbno += resv->used;
> > + resv->len -= resv->used;
> > + resv->used = 0;
> > +
> > + if (resv->len > 0) {
> > + trace_xrep_newbt_unreserve_space(sc->mp,
> > + XFS_FSB_TO_AGNO(sc->mp, resv->fsbno),
> > + XFS_FSB_TO_AGBNO(sc->mp, resv->fsbno),
> > + resv->len, xnr->oinfo.oi_owner);
> > +
> > + __libxfs_bmap_add_free(sc->tp, resv->fsbno, resv->len,
> > + &xnr->oinfo, true);
TBH for repair I don't even think we need this, since in theory we
reserved *exactly* the correct number of blocks for the btree. Hmm.
> > + }
> > +
> > + list_del(&resv->list);
> > + kmem_free(resv);
> > + }
> > +
> > +junkit:
> > + list_for_each_entry_safe(resv, n, &xnr->reservations, list) {
> > + list_del(&resv->list);
> > + kmem_free(resv);
> > + }
> > +
> > + if (sc->ip) {
> > + kmem_cache_free(xfs_ifork_zone, xnr->ifake.if_fork);
> > + xnr->ifake.if_fork = NULL;
> > + }
> > +}
> > +
> ...
> > diff --git a/repair/xfs_repair.c b/repair/xfs_repair.c
> > index 9d72fa8e..8fbd3649 100644
> > --- a/repair/xfs_repair.c
> > +++ b/repair/xfs_repair.c
> ...
> > @@ -49,6 +52,8 @@ static char *o_opts[] = {
> > [AG_STRIDE] = "ag_stride",
> > [FORCE_GEO] = "force_geometry",
> > [PHASE2_THREADS] = "phase2_threads",
> > + [BLOAD_LEAF_SLACK] = "debug_bload_leaf_slack",
> > + [BLOAD_NODE_SLACK] = "debug_bload_node_slack",
>
> Why the "debug_" in the option names?
These are debugging knobs; there's no reason why any normal user would
want to override the automatic slack sizing algorithms. I also
refrained from documenting them in the manpage. :P
However, the knobs have been useful for stress-testing w/ fstests.
--D
> Brian
>
> > [O_MAX_OPTS] = NULL,
> > };
> >
> > @@ -260,6 +265,18 @@ process_args(int argc, char **argv)
> > _("-o phase2_threads requires a parameter\n"));
> > phase2_threads = (int)strtol(val, NULL, 0);
> > break;
> > + case BLOAD_LEAF_SLACK:
> > + if (!val)
> > + do_abort(
> > + _("-o debug_bload_leaf_slack requires a parameter\n"));
> > + bload_leaf_slack = (int)strtol(val, NULL, 0);
> > + break;
> > + case BLOAD_NODE_SLACK:
> > + if (!val)
> > + do_abort(
> > + _("-o debug_bload_node_slack requires a parameter\n"));
> > + bload_node_slack = (int)strtol(val, NULL, 0);
> > + break;
> > default:
> > unknown('o', val);
> > break;
> >
>
next prev parent reply other threads:[~2020-05-14 19:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-09 16:31 [PATCH v4 0/9] xfs_repair: use btree bulk loading Darrick J. Wong
2020-05-09 16:31 ` [PATCH 1/9] xfs_repair: port the online repair newbt structure Darrick J. Wong
2020-05-14 15:09 ` Brian Foster
2020-05-14 19:20 ` Darrick J. Wong [this message]
2020-05-15 11:41 ` Brian Foster
2020-05-15 18:52 ` Darrick J. Wong
2020-05-15 19:43 ` Brian Foster
2020-05-09 16:31 ` [PATCH 2/9] xfs_repair: unindent phase 5 function Darrick J. Wong
2020-05-14 15:09 ` Brian Foster
2020-05-14 19:23 ` 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-05-09 16:32 ` [PATCH 4/9] xfs_repair: rebuild free space btrees with bulk loader Darrick J. Wong
2020-05-14 15:12 ` Brian Foster
2020-05-14 19:53 ` Darrick J. Wong
2020-05-15 11:42 ` Brian Foster
2020-05-09 16:32 ` [PATCH 5/9] xfs_repair: rebuild inode " Darrick J. Wong
2020-05-09 16:32 ` [PATCH 6/9] xfs_repair: rebuild reverse mapping " Darrick J. Wong
2020-05-09 16:32 ` [PATCH 7/9] xfs_repair: rebuild refcount " Darrick J. Wong
2020-05-09 16:32 ` [PATCH 8/9] xfs_repair: remove old btree rebuild support code Darrick J. Wong
2020-05-09 16:32 ` [PATCH 9/9] xfs_repair: track blocks lost during btree construction via extents Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
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-03-04 3:29 [PATCH v3 0/9] xfs_repair: use btree bulk loading Darrick J. Wong
2020-03-04 3:29 ` [PATCH 1/9] xfs_repair: port the online repair newbt structure 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 1/9] xfs_repair: port the online repair newbt structure 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 1/9] xfs_repair: port the online repair newbt structure 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=20200514192037.GD6714@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).