Stefan Priebe wrote on 2015/11/01 21:49 +0100:
Hi,
this one: http://www.spinics.net/lists/linux-btrfs/msg47377.html
adds a regression to my test systems with very large disks (30tb and 50tb).
btrfs balance is super slow afterwards while heavily making use of cp
--reflink=always on big files (200gb - 500gb).
Sorry didn't know how to correctly reply to that "old" message.
Greets,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks for the testing.
Are you using qgroup or just doing normal balance with qgroup disabled?
For the latter case, that's should be optimized to skip the dirty extent
insert in qgroup disabled case.
For qgroup enabled case, I'm afraid that's the design.
As relocation will drop a subtree to relocate, and to ensure qgroup
consistent, we must walk down all the tree blocks and mark them dirty
for later qgroup accounting.
But there should be some hope left for optimization.
For example, if all subtree blocks are already relocated, we can skip
the tree down walk routine.
Anyway, for your case of huge files, as tree level grows rapidly, any
workload involving tree iteration will be very time consuming.
Like snapshot deletion and relocation.
BTW, thanks for you regression report, I also found another problem of
the patch.
I'll reply to the author to improve the patchset.
Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
