Date: Fri, 26 Mar 2021 10:37:47 +0100 From: Mathieu Chouquet-Stringer <me+freebsd@mathieu.digital> To: Matt Churchyard <matt.churchyard@userve.net> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, current@freebsd.org Subject: Re: Scrub incredibly slow with 13.0-RC3 (as well as RC1 & 2) Message-ID: <YF2raxOUeN8Y23eT@weirdfishes> In-Reply-To: <33eb78e2de404a77b271880dbee4c22e@SERVER.ad.usd-group.com> References: <YFhuxr0qRzchA7x8@weirdfishes> <202103221515.12MFFHRK015188@higson.cam.lispworks.com> <YFi6Lwh3ISn8UMvS@weirdfishes> <YFk11A/j7URClN/l@weirdfishes> <YFm3BTK/J9XY/mCN@weirdfishes> <202103241230.12OCUqur030001@higson.cam.lispworks.com> <YFs3jFT7sEaGeQCe@weirdfishes> <33eb78e2de404a77b271880dbee4c22e@SERVER.ad.usd-group.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 25, 2021 at 08:55:12AM +0000, Matt Churchyard wrote:
> Just an a aside, I did post a message a few weeks ago with a similar
> problem on 13 (as well as snapshot issues). Scrub seemed ok for a
> short while, but then ground to a halt. It would take 10+ minutes to
> go 0.01%, with everything appearing fairly idle. I finally gave up and
> stopped it after about 20 hours. Moving to 12.2 and rebuilding the
> pool, the system scrubbed the same data in an hour, and I've just
> scrubbed the same system after a month of use with about 4 times the
> data in 3 hours 20. As far as I'm aware, both should be using
> effectively the same "new" scrub code.
>
> Will be interesting if you find a cause as I didn't get any response
> to what for me was a complete showstopper for moving to 13.
Bear with me, I'm slowly resilvering now... But same thing, it's not
even maxing out my slow drives... Looks like it'll take 2 days...
I did some flame graphs using dtrace. The first one is just the output
of that:
dtrace -x stackframes=100 -n 'profile-99 /arg0/ { @[stack()] = count(); } tick-60s { exit(0); }'
Clearly my machine is not busy at all.
And the second is the output of pretty much the same thing except I'm
only capturing pid 31 which is the one busy.
dtrace -x stackframes=100 -n 'profile-99 /arg0 && pid == 31/ { @[stack()] = count(); } tick-60s { exit(0); }'
One striking thing is how many times hpet_get_timecount is present...
--
Mathieu Chouquet-Stringer mchouque@free.fr
The sun itself sees not till heaven clears.
-- William Shakespeare --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YF2raxOUeN8Y23eT>