Re: raid6check extremely slow ?

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

On Wed, May 13, 2020 at 06:37:18PM +0100, Wols Lists wrote:
> 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" :-)

We need to consider all posibilities...
 
> > 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.

Ah! Thank you.
That's always confusing me. Usually I check
with some search engine, but sometimes I'm
too lazy... And then I forgot.

BTW, somehow related, please do not
refrain to correct my English.

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

Well, as Neil would say, patch are welcome! :-)

Really, I've too little time to make
changes to the code.
I can do some test and, hopefully,
some support.

bye,

pg

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

-- 

piergiorgio