From: Sun Yangkai <sunk67188@gmail.com>
To: Boris Burkov <boris@bur.io>
Cc: kernel-team@fb.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: make periodic dynamic reclaim the default for data
Date: Tue, 30 Dec 2025 09:41:12 +0800 [thread overview]
Message-ID: <17b6ed66-6427-4098-8574-ac780cc1103b@gmail.com> (raw)
In-Reply-To: <aVMWI7bVCZX4RAAa@devvm12410.ftw0.facebook.com>
> Please let me know if I can assist you with that, or if you do have a
> reproducer I could also look at.
I just come with a ... thing I found and I have no idea why it happened.
I've wrote a script to show the 10 least used block groups(used_space is just
calculated from length and used_pct, so please just ignore them) and before
periodic reclaim, I got:
Searching for the 10 least used DATA block groups...
vaddr length used_pct used_space
--------------------------------------------------------
6353387388928 1024MiB 5% 51MiB
6354461130752 1024MiB 30% 307MiB
6295292084224 1024MiB 80% 819MiB
6056900427776 1024MiB 89% 911MiB
4620552634368 1024MiB 97% 993MiB
6050457976832 1024MiB 98% 1003MiB
6122398679040 1024MiB 98% 1003MiB
6270596022272 1024MiB 98% 1003MiB
6350166163456 1024MiB 98% 1003MiB
383347851264 1024MiB 99% 1013MiB
And unallocated space is 3GiB so with dynamic periodic reclaim, the first two
block groups will be reclaimed:
[12月28 21:47] [ T357] BTRFS info (device sda): relocating block group
6353387388928 flags data
[ +0.262467] [ T357] BTRFS info (device sda): found 1970 extents, stage: move
data extents
[ +1.334556] [ T357] BTRFS info (device sda): found 1966 extents, stage:
update data pointers
[ +0.618457] [ T357] BTRFS info (device sda): relocating block group
6354461130752 flags data
[ +1.009694] [ T357] BTRFS info (device sda): found 166 extents, stage: move
data extents
[ +0.388070] [ T357] BTRFS info (device sda): found 166 extents, stage: update
data pointers
And after the reclaim I got:
Searching for the 10 least used DATA block groups...
vaddr length used_pct used_space
--------------------------------------------------------
6355534872576 1024MiB 6% 61MiB
6356608614400 1024MiB 16% 163MiB
6295292084224 1024MiB 80% 819MiB
4620552634368 1024MiB 97% 993MiB
6050457976832 1024MiB 98% 1003MiB
6270596022272 1024MiB 98% 1003MiB
3782605471744 1024MiB 99% 1013MiB
4549685673984 1024MiB 99% 1013MiB
5882820034560 1024MiB 99% 1013MiB
5909764243456 1024MiB 99% 1013MiB
These two block groups could be merged into existing chunks, but I have no idea
why that didn't happen. But when I run
btrfs balance start -dvrange=6355534872576..6355534872576 /mnt
It can be merged and free some unallocated space.
So I think the periodic reclaim has a different behavior with manually balance?
Thanks,
Sun YangKai
prev parent reply other threads:[~2025-12-30 1:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 18:58 [PATCH] btrfs: make periodic dynamic reclaim the default for data Boris Burkov
2025-07-16 6:24 ` Johannes Thumshirn
2025-07-16 15:56 ` Boris Burkov
2025-07-17 12:55 ` Johannes Thumshirn
2025-10-21 18:52 ` Chris Murphy
2025-10-21 22:39 ` Leo Martins
2025-10-22 0:37 ` Chris Murphy
2025-10-22 1:02 ` Boris Burkov
2025-10-23 23:27 ` Leo Martins
2025-12-13 22:09 ` Neal Gompa
2025-12-26 3:07 ` Sun Yangkai
2025-12-30 0:00 ` Boris Burkov
2025-12-30 1:29 ` Sun Yangkai
2025-12-30 1:41 ` Sun Yangkai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17b6ed66-6427-4098-8574-ac780cc1103b@gmail.com \
--to=sunk67188@gmail.com \
--cc=boris@bur.io \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox