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
