From: Alex Elder <aelder@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs_repair: multithread phase 2
Date: Wed, 05 Jan 2011 17:42:14 -0600 [thread overview]
Message-ID: <1294270934.2312.105.camel@doink> (raw)
In-Reply-To: <1294121588-17233-1-git-send-email-david@fromorbit.com>
On Tue, 2011-01-04 at 17:13 +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> Running some recent repair tests on broken filesystem meant running
> phase 1 and 2 repeatedly to reproduce an issue at the start of phase
> 3. Phase 2 was taking approximately 10 minutes to run as it
> processes each AG serially.
>
> Phase 2 can be trivially parallelised - it is simply scanning the
> per AG trees to calculate free block counts and free and used inodes
> counts. This can be done safely in parallel by giving each AG it's
> own structure to aggregate counts into, then once the AG scan is
> complete adding them all together.
>
> This patch uses 32-way threading which results in no noticable
> slowdown on single SATA drives with NCQ, but results in ~10x
> reduction in runtime on a 12 disk RAID-0 array.
This is great. And evidently not very hard at all. It should
have been done a long time ago...
I had a few of the same comments Christoph had (though
I didn't know about the the workqueues). I'll reiterate
one, that SCAN_THREADS should be a command line option.
32 is a fine default, but there's no sense in restricting
it to that.
A few other things, below, but this looks good to me.
Reviewed-by: Alex Elder <aelder@sgi.com>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
> repair/phase2.c | 16 +---
> repair/scan.c | 303 +++++++++++++++++++++++++++++++-----------------------
> repair/scan.h | 37 -------
> 3 files changed, 176 insertions(+), 180 deletions(-)
. . .
> diff --git a/repair/scan.c b/repair/scan.c
> index 85017ff..dd62776 100644
> --- a/repair/scan.c
> +++ b/repair/scan.c
. . .
> @@ -469,6 +477,34 @@ _("out-of-order bmap key (file offset) in inode %llu, %s fork, fsbno %llu\n"),
> }
>
Can this (and scanfunc_cnt() and scanfunc_ino()) be given
static scope now?
> void
> +scanfunc_bno(
> + struct xfs_btree_block *block,
> + int level,
> + xfs_agblock_t bno,
> + xfs_agnumber_t agno,
> + int suspect,
> + int isroot,
> + struct aghdr_cnts *agcnts)
> +{
> + return scanfunc_allocbt(block, level, bno, agno,
> + suspect, isroot, XFS_ABTB_MAGIC, agcnts);
> +}
> +
. . .
> @@ -1155,42 +1169,15 @@ validate_agi(
> }
. . .
> -void
> -scan_ag(
> - xfs_agnumber_t agno)
> +void *
> +scan_ag(void *args)
Maybe arg (singular)
> {
> + struct aghdr_cnts *agcnts = args;
> + xfs_agnumber_t agno = agcnts->agno;
> xfs_agf_t *agf;
> xfs_buf_t *agfbuf;
> int agf_dirty = 0;
. . .
> @@ -1331,4 +1308,72 @@ scan_ag(
> libxfs_putbuf(sbbuf);
> free(sb);
> PROG_RPT_INC(prog_rpt_done[agno], 1);
> +
> +#ifdef XR_INODE_TRACE
> + print_inode_list(i);
I know this is only under XR_INODE_TRACE, but
now that you're multi-threading these, the
output can get interleaved and therefore
somewhat useless. Maybe you could adjust
print_inode_list() so it includes the AG
number with each line output rather than
just prior to printing all of them.
> +#endif
> + return NULL;
> +}
> +
> +#define SCAN_THREADS 32
Make this configurable at runtime.
> +
> +void
> +scan_ags(
> + struct xfs_mount *mp)
> +{
> + struct aghdr_cnts agcnts[mp->m_sb.sb_agcount];
There is some mention about the per-thread stack size
getting set at the time the program starts in the pthread
documentation. I don't expect this will be a problem in
practice, but maybe this should be allocated dynamically.
> + pthread_t thr[SCAN_THREADS];
> + __uint64_t fdblocks = 0;
> + __uint64_t icount = 0;
> + __uint64_t ifreecount = 0;
> + int i, j, err;
> +
> + /*
> + * scan a few AGs in parallel. The scan is IO latency bound,
> + * so running a few at a time will speed it up significantly.
> + */
> + for (i = 0; i < mp->m_sb.sb_agcount; i += SCAN_THREADS) {
> + for (j = 0; j < SCAN_THREADS; j++) {
xfs_agnumber_t agno = i + j;
> + if (i + j >= mp->m_sb.sb_agcount)
if (agno >= mp->m_sb.sg_agcount)
(and so on, throughout this section)
> + break;
> + memset(&agcnts[i + j], 0, sizeof(agcnts[i]));
agcnts[i + j]
> + agcnts[i + j].agno = i + j;
> + err = pthread_create(&thr[j], NULL, scan_ag,
> + &agcnts[i + j]);
> + if (err)
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-01-05 23:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-04 6:13 [PATCH] xfs_repair: multithread phase 2 Dave Chinner
2011-01-04 10:02 ` Christoph Hellwig
2011-01-04 12:00 ` Dave Chinner
2011-01-05 23:42 ` Alex Elder [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-01-10 0:44 Dave Chinner
2011-01-10 7:57 ` Michael Monnerie
2011-01-10 8:41 ` Dave Chinner
2011-01-10 13:25 ` Michael Monnerie
2011-01-10 19:18 ` Christoph Hellwig
2011-01-10 19:17 ` Christoph Hellwig
2011-01-10 21:53 ` Matthias Schniedermeyer
2011-01-10 18:55 ` Christoph Hellwig
2011-02-01 23:39 ` Alex Elder
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=1294270934.2312.105.camel@doink \
--to=aelder@sgi.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.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.