On 2020/12/22 上午3:45, René Rebe wrote:
Hey there,
as a long time btrfs user I noticed some some things became very slow
w/ Linux kernel 5.10. I found a very simple test case, namely extracting
a huge tarball like:
tar xf /usr/src/t2-clean/download/mirror/f/firefox-84.0.source.tar.zst
Why my external, USB3 road-warrior SSD on a Ryzen 5950x this
went from ~15 seconds w/ 5.9 to nearly 5 minutes in 5.10, or 2000%
To rule out USB, I also tested a brand new PCIe 4.0 SSD, with
a similar, albeit not as shocking regression from 5.2 seconds
to ~34 seconds or∫~650%.
Somehow testing that in a VM did over virtio did not produce
as different results, although it was already 35 seconds slow
with 5.9.
# first bad commit: [38d715f494f2f1dddbf3d0c6e50aefff49519232]
btrfs: use btrfs_start_delalloc_roots in shrink_delalloc
This means metadata space is not enough and we go shrink_delalloc() to
free some metadata space.
My concern is, why we need to go shrink_delalloc() in the first place.
Normally either the fs has enough unallocated space (thus we can
over-commit) or has enough unused metadata space.
We only need to shrink delalloc if we have no unallocated space, and not
enough space for the over-estimated metadata reserve.
Would you please try to provide the `btrfs fi usage` output of your test
drive?
My initial guess is, this is related to fs usage/layout.
Thanks,
Qu
Now just this single commit does obviously not revert cleanly,
and I did not have the time today to look into the rather more
complex code today.
I hope this helps improve this for the next release, maybe you
want to test on bare metal, too.
Greetings,
René https://youtu.be/NhUMdvLyKJc
