On Wed, May 13, 2020 at 06:37:18PM +0100, Wols Lists wrote:

On 13/05/20 17:18, Piergiorgio Sartor wrote:

quoted

On Tue, May 12, 2020 at 09:54:21PM +0100, antlists wrote:

quoted

On 12/05/2020 17:09, Piergiorgio Sartor wrote:

quoted

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

quoted

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

quoted

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.

quoted

quoted

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.

quoted

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

quoted

bye,

pg

Cheers,
Wol

quoted

quoted

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