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

Filipe Manana
2021-12-07T15:54:08Z

On Tue, Dec 7, 2021 at 3:41 PM David Sterba <dsterba@suse.cz> wrote:
>
> On Tue, Dec 07, 2021 at 03:53:29PM +0100, David Sterba wrote:
> > On Tue, Dec 07, 2021 at 08:01:04PM +0800, Qu Wenruo wrote:
> > > On 2021/12/7 19:56, Filipe Manana wrote:
> > > > On Tue, Dec 07, 2021 at 07:43:49PM +0800, Qu Wenruo wrote:
> > > >> On 2021/12/7 19:02, Filipe Manana wrote:
> > > >>> On Tue, Dec 07, 2021 at 03:43:58PM +0800, Qu Wenruo wrote:
> > > >>>> This is originally just my preparation for scrub refactors, but when the
> > > >>>> readahead is involved, it won't just be a small cleanup.
> > > >>>>
> > > >>>> The metadata readahead code is introduced in 2011 (surprisingly, the
> > > >>>> commit message even contains changelog), but now only one user for it,
> > > >>>> and even for the only one user, the readahead mechanism can't provide
> > > >>>> much help in fact.
> > > >>>>
> > > >>>> Scrub needs readahead for commit root, but the existing one can only do
> > > >>>> current root readahead.
> > > >>>
> > > >>> If support for the commit root is added, is there a noticeable speedup?
> > > >>> Have you tested that?
> > > >>
> > > >> Will craft a benchmark for that.
> > > >>
> > > >> Although I don't have any HDD available for benchmark, thus would only
> > > >> have result from SATA SSD.
> >
> > 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?
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.

Thanks.