Re: Regression in: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

[Stefan Priebe <s.priebe@profihost.ag>]

Am 02.11.2015 um 02:34 schrieb Qu Wenruo:
>
>
> 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@vger.kernel.org
>> 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?

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,
Stefan


> Thanks,
> Qu