Re: raid6check extremely slow ?

[Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>]

On Tue, May 12, 2020 at 09:54:21PM +0100, antlists wrote:
> On 12/05/2020 17:09, Piergiorgio Sartor wrote:
> > About the check -> maybe lock -> re-check,
> > it is a possible workaround, but I find it
> > a bit extreme.
> 
> This seems the best (most obvious?) solution to me.
> 
> If the system is under light write pressure, and the disk is healthy, it
> will scan pretty quickly with almost no locking.

I've some concerns about optimization
solutions which can result in less
performances than the original status.

You mention "write pressure", but there
is an other case, which will cause
read -> lock -> re-read...
Namely, when some chunk is really corrupted.

Now, I do not know, maybe there are other
things we overlook, or maybe not.

I do not know either how likely is that some
situations will occur to reduce performances.

I would prefer a solution which will *only*
improve, without any possible drawback.

Again, this does not mean this approach is
wrong, actually is to be considered.

In the end, I would like also to understand
why the lock / unlock is so expensive.

> If the system is under heavy pressure, chances are there'll be a fair few
> stripes needing rechecking, but even at it's worst it'll only be as bad as
> the current setup.

It will be worse (or worst, I'm always
confused...).
The read and the check will double.

I'm not sure about the read, but the
check is currently expensive.

bye,

pg

> And if the system is somewhere inbetween, you still stand a good chance of a
> fast scan.
> 
> At the end of the day, the rule should always be "lock only if you need to"
> so looking for problems with an optimistic no-lock scan, then locking only
> if needed to check and fix the problem, just feels right.
> 
> Cheers,
> Wol

-- 

piergiorgio