Re: [PATCH RFC 0/2] btrfs: remove the metadata readahead mechanism

David Sterba
2021-12-08T14:04:29Z

On Tue, Dec 07, 2021 at 03:53:22PM +0000, Filipe Manana wrote:
> > > 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.
>
> >
> > 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.