Re: Deleting large amounts of data causes system freeze due to OOM.

[fdavidl073rnovn@tutanota.com]

Sep 13, 2023, 05:55 by wqu@suse.com:

>
>
> On 2023/9/13 11:58, fdavidl073rnovn@tutanota.com wrote:
>
>> Dear Btrfs Mailing List,
>>
>> Full disclosure I reported this on kernel.org but am hoping to get more exposure on the mailing list.
>>
>> When I delete several terabytes of data memory usage increases until the system becomes entirely unresponsive. This has been an issue for several kernel version since at least 5.19 and continues to be an issue up to 6.5.2-artix1-1. This is on an older computer with several hard drives, eight gigabytes of memory, and a four core x86_64 cpu. Slabtop output right before the system becomes unresponsive shows about four gigabytes used by khugepaged_mm_slot and three used by btrfs_extent_map. This happens in over the span of a couple minutes and during this time btrfs-transaction is using a moderate amount of cpu time.
>>
>
> This looks exactly like something caused by btrfs qgroup.
>
> Could you try to disable qgroup to see if it helps?
> The amount of CPU time and IO of qgroup overhead is directly related to the amount of extent being updated.
>
> For normal writes the IO itself would take most of the CPU/memory thus qgroup is not a big deal.
> But for massive snapshots drop or file deletion qgroup can be too large to be handled in just one transaction.
>
> For now you can disable the qgroup as a workaround.
>
> Thanks,
> Qu
>
I've never enabled quotas and my most recent attempt using the single profile for data was on kernel 6.4 so they would have been disabled by default. Running "btrfs qgroup show [path]" returns "ERROR: can't list qgroups: quotas not enabled".

Sincerely,
David