Re: raid6check extremely slow ?

[Wols Lists <antlists@youngman.org.uk>]

On 13/05/20 17:18, Piergiorgio Sartor wrote:
> 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.
> 
Yup. That's why I said "the disk is healthy" :-)

> 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.

Wouldn't we all. But if the *normal* case shows an appreciable
improvement, then I'm inclined to write off a "shouldn't happen" case as
"tough luck, shit happens".
> 
> 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.

Agreed.
> 
>> 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.

Touche - my logic was off ...

But a bit of grammar - bad = descriptive, worse = comparative, worst =
absolute, so you were correct with worse.
> 
> I'm not sure about the read, but the
> check is currently expensive.

But you're still going to need a very unlucky state of affairs for the
optimised check to be worse. Okay, if the disk IS damaged, then the
optimised check could easily be the worst, but if it's just write
pressure, you're going to need every second stripe to be messed up by a
collision. Rather unlikely imho.
> 
> bye,
> 
> pg

Cheers,
Wol
> 
>> 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
>