Re: clear space cache v1 fails with Unable to find block group for 0

[Qu Wenruo <wqu@suse.com>]

在 2024/12/17 16:01, j4nn 写道:
> On Mon, 16 Dec 2024 at 19:52, j4nn <j4nn.xda@gmail.com> wrote:
>>
>> This is unrelated, but as you have been interested in the hung task
>> backtrace, I got two more when using "btrfs send ... | btrfs receive
>> ..." to copy 7TB of data from one btrfs disk to another one (still in
>> progress, both rotational hard drives):
>> [81837.347137] INFO: task btrfs-transacti:29385 blocked for more than
>> 122 seconds.
>> [81837.347144]       Tainted: G        W  O       6.12.3-gentoo-x86_64 #1
>> [81837.347147] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> disables this message.
>> [81837.347149] task:btrfs-transacti state:D stack:0     pid:29385
>> tgid:29385 ppid:2      flags:0x00004000
>> [81837.347154] Call Trace:
>> [81837.347156]  <TASK>
>> [81837.347161]  __schedule+0x3f0/0xbd0
>> [81837.347170]  schedule+0x27/0xf0
>> [81837.347174]  io_schedule+0x46/0x70
>> [81837.347177]  folio_wait_bit_common+0x123/0x340
>> [81837.347184]  ? __pfx_wake_page_function+0x10/0x10
>> [81837.347189]  folio_wait_writeback+0x2b/0x80
>> [81837.347193]  __filemap_fdatawait_range+0x7d/0xd0
>> [81837.347201]  filemap_fdatawait_range+0x12/0x20
>> [81837.347206]  __btrfs_wait_marked_extents.isra.0+0xb8/0xf0 [btrfs]

This is from the metadata writeback.

My guess is, since you're transfering a lot of data, the metadata also 
go very large very fast.

And the default commit interval is 30s, and considering your hardware, 
your hardware memory may also be pretty large (at least 32G I believe?).

That means we can have several giga bytes of metadata waiting to be 
written back.

What makes things worse may be the fact that, metadata writeback 
nowadays are always in nodesize, no merging at all.

Furthermore since your storage device is HDD, the low IOPS performance 
is making it even worse.


Combining all those things together, we're writing several giga bytes of 
metadata, all in 16K nodesize no merging, resulting a very bad write 
performance on rotating disks...

IIRC there are some ways to limit how many bytes can be utilized by page 
cache (btrfs metadata is also utilizing page cache), thus it may improve 
the situation by not writing too much metadata in one go.

[...]
> 
> The destination btrfs filesystem has been freshly created (single
> device, no raid) and thus empty before starting the transfer.
> This is output of destination 'btrfs filesystem df' after the transfer:
> Data, single: total=7.10TiB, used=7.06TiB
> System, DUP: total=8.00MiB, used=768.00KiB
> Metadata, DUP: total=8.00GiB, used=7.53GiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
> 
> The btrfs is on a luks device (cryptsetup -h sha512 -c aes-xts-plain64
> -s 256), but cpu has been idle the whole time (ryzen 5950x).


Considering the transfer finished, and you can unmount the fs, it should 
really be a false alert, mind to share how large your RAM is?
32G or even 64G?

Thanks,
Qu
> 
> Hope that helps.
> Thank you.
>