On Tue, Dec 07, 2021 at 03:53:22PM +0000, Filipe Manana wrote:

quoted

quoted

I'm doing some tests, in a VM on a dedicated HDD.

There's some measurable difference:

With readahead:

Duration:         0:00:20
Total to scrub:   7.02GiB
Rate:             236.92MiB/s

Duration:         0:00:48
Total to scrub:   12.02GiB
Rate:             198.02MiB/s

Without readahead:

Duration:         0:00:22
Total to scrub:   7.02GiB
Rate:             215.10MiB/s

Duration:         0:00:50
Total to scrub:   12.02GiB
Rate:             190.66MiB/s

The setup is: data/single, metadata/dup, no-holes, free-space-tree,
there are 8 backing devices but all reside on one HDD.

Data generated by fio like

fio --rw=randrw --randrepeat=1 --size=3000m \
         --bsrange=512b-64k --bs_unaligned \
         --ioengine=libaio --fsync=1024 \
         --name=job0 --name=job1 \

and scrub starts right away this. VM has 4G or memory and 4 CPUs.

How about using bare metal? And was it a debug kernel, or a default
kernel config from a distro?

It was the debug config I use for normal testing, I'll try to redo it on
another physical box.

Those details often make all the difference (either for the best or
for the worse).

I'm curious to see as well the results when:

1) The reada.c code is changed to work with commit roots;

2) The standard btree readahead (struct btrfs_path::reada) is used
instead of the reada.c code.

quoted

The difference is 2 seconds, roughly 4% but the sample is not large
enough to be conclusive.

A bit too small.

What's worse, I did a few more rounds and the results were too unstable,
from 44 seconds to 25 seconds (all on the removed readahead branch), but
the machine was not quiescent.