Re: Btrfs autodefrag wrote 5TB in one day to a 0.5TB SSD without a measurable benefit

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/3/12 00:31, Jan Ziak wrote:
> On Fri, Mar 11, 2022 at 6:04 AM Jan Ziak <0xe2.0x9a.0x9b@gmail.com> wrote:
>>
>> On Fri, Mar 11, 2022 at 3:59 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>> A few outliners can also be fixed by a upcoming patch:
>>> https://patchwork.kernel.org/project/linux-btrfs/patch/d1ce90f37777987732b8ccf0edbfc961cd5c8873.1646912061.git.wqu@suse.com/
>>>
>>> But please note that, the extra patch won't bring a bigger impact as the
>>> previous one, it's mostly a small optimization.
>>
>> I will apply and test the patch and report results.
>
> $ uptime
> 10h54m
>
> CPU time of pid 297: 1h48m
>
> $ cat /proc/297/io  (pid 297 is btrfs-cleaner)
> read_bytes: 4_433_081_716_736
> write_bytes: 788_509_859_840
>
> file.sqlite, before 10h54m: 1827586 extents
>
> file.sqlite, after 10h54m: 1876144 extents
>
> Summary: File fragmentation increased by 48558 extents despite the
> fact that btrfs-cleaner read 4.4 TB, wrote 788 GB and consumed 1h48m
> of CPU time.
>
> If it helps, I can send you the complete list of all the 1.8 million
> extents. I am not sure how long it might take to obtain such a list.

As stated before, autodefrag is not really that useful for database.

So my primary objective here is to make autodefrag cause less CPU/IO for
the worst case scenario.

BTW, have you compared to the number of extents with, or without using
autodefrag?

Thanks,
Qu

>
> -Jan