Re: Scrub of my nvme SSD has slowed by about 2/3

[Martin Steigerwald <martin@lichtvoll.de>]

Qu Wenruo - 11.07.23, 10:59:55 CEST:
> On 2023/7/11 13:52, Martin Steigerwald wrote:
> > Martin Steigerwald - 11.07.23, 07:49:43 CEST:
> >> I see about 180000 reads in 10 seconds in atop. I have seen latency
> >> values from 55 to 85 µs which is highly unusual for NVME SSD
> >> ("avio"
> >> in atop¹).
> > 
> > Well I did not compare to a base line during scrub with 6.3. So not
> > actually sure about the unusual bit. But at least during daily
> > activity I do not see those values.
> > 
> > Anyway, I am willing to test a patch.
> 
> Mind to try the following branch?
> 
> https://github.com/adam900710/linux/tree/scrub_multi_thread
> 
> Or you can grab the commit on top and backport to any kernel >= 6.4.

Cherry picking the commit on top of v6.4.3 lead to a merge conflict. 
Since this is a production machine and I am no kernel developer with 
insight to the inner workings of BTRFS, I'd prefer a patch that applies 
cleanly on top of v6.4.3. I'd rather not try out a tree, unless I know 
its a stable kernel version or at least rc3/4 or later. Again this is a 
production machine.

You know, I prefer to keep my data :)

> Thanks,
> Qu
> 
> >> [1] according to man page atop(1) from atop 2.9:
> >> 
> >> the average number of milliseconds needed by a request ('avio') for
> >> seek, latency and data transfer


-- 
Martin