On 2019-01-14 21:34, Qu Wenruo wrote:
On 2019/1/14 下午7:47, Tomasz Chmielewski wrote:
When rebasing my qgroup + balance optimization patches, I found one
very
obvious performance regression for balance.
For normal 4G subvolume, 16 snapshots, balance workload, v4.20 kernel
only takes 3s to relocate a metadata block group, while for v5.0-rc1,
I
don't really know how it will take as it hasn't finished yet.
Are you sure it's v5.0-rc1 regression, not earlier?
At least for what I'm describing, yes. v5.0-rc1 introduced bug, and
already pinned down.
So I'm afraid you're hitting another different bug.
I'm trying to do a metadata-only balance from RAID-5 to RAID-1, with
4.19.8.
It was going relatively "normal", until it got stuck and showing no
progress.
I've canceled the balance, upgraded to 4.20, started the balance
again.> For straight 11 days, it rewrote terabytes of data on the
disks, with no
progress at all.> Also, 4.19.8 had a balance interrupted because of
"out
of space", despite we have terabytes free.
Metadata RAID-5 usage stays at 4.12GiB for the past 11 days (and a few
more days with 4.19.8).
Are you using qgroup? Which is another huge cause of slow balance.
No, no qgroups.
# btrfs quota rescan /data
ERROR: quota rescan failed: Invalid argument
