From: Leszek Dubiel <leszek@dubiel.pl>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: 97% full system, dusage didn't help, musage strange
Date: Fri, 3 Jan 2025 23:52:30 +0100 [thread overview]
Message-ID: <000bcef0-a86e-4832-90bb-9a4a47afad6d@dubiel.pl> (raw)
In-Reply-To: <a6a641f6-b0a1-4915-912a-638cc07eba88@suse.com>
W dniu 16.12.2024 o 22:01, Qu Wenruo pisze:
> If you want to be extra safe, the best solution is to use tools that
can report the usage percentage of each block group.
>
> You need something procedure like this:
>
> start:
> if (unallocated space >= 8GiB)
> return;
> check_usage_percentage:
> if (no block group has usage percentage < 30%) {
> delete_files;
> goto check_usage_percentage;
> }
> balance dusage=30
> goto start;
>
> Although there are some concerns, firstly the tool, sorry I didn't
remember the name but there is an out-of-btrfs-progs tool can do exactly
that.
In btrfs-progs package I didn't find any such tool.
There is "btrfs maintenance" by kdave:
https://github.com/kdave/btrfsmaintenance
but it starts normal balance, it doesn't analize "block usage percentage".
>> How to improve?
>>
>> Tell the first procedure to keep 500GB free space? 800GB?
>
> Increasing the free space will definitely increase the chance of
reclaiming space using balance.
>
> But that's only increasing the chance, never to ensure that.
>
> As you can keep 800GiB free space, but since your fs have 8TiB data
space, for the worst case scenario where all space are freed evenly
among all chunks, it means each 1GiB chunk will only have around 100MiB
(10%) freed.
>
> That is not really going to chance the result of balance.
> But that's for the worst case scenario.
I think I'm hitting the worst case scenario again and again.
It looks as if my BTRFS system is always going towards that situation
where "all space are freed evenly among all chunks".
I wrote a script that ensures:
— at least 200 GB free disk space
— at least 5% free disk space
Then another script to balance btrfs when there is low "Unallocated space".
It got stuck:
# df -h ./sdc3/
Filesystem Size Used Avail Use% Mounted on
/dev/sdc3 2.7T 2.5T 226G 92% /mnt/leszek/sdc3
# btrfs filesystem usage ./sdc3 -T
Overall:
Device size: 2.70TiB
Device allocated: 2.68TiB
Device unallocated: 19.45GiB
Device missing: 0.00B
Device slack: 3.50KiB
Used: 2.47TiB
Free (estimated): 225.94GiB (min: 216.21GiB)
Free (statfs, df): 225.87GiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 32.00KiB)
Multiple profiles: no
Data Metadata System
Id Path single DUP DUP Unallocated Total Slack
-- --------- ------- -------- --------- ----------- ------- -------
1 /dev/sdc3 2.64TiB 36.00GiB 64.00MiB 19.45GiB 2.70TiB 3.50KiB
-- --------- ------- -------- --------- ----------- ------- -------
Total 2.64TiB 18.00GiB 32.00MiB 19.45GiB 2.70TiB 3.50KiB
Used 2.44TiB 17.08GiB 432.00KiB
I have tried different combinations of musage, dusage...
btrfs balance start -dusage=30,limit=5 ./sdc3/
btrfs balance start -dusage=50,limit=5 ./sdc3/
btrfs balance start -dusage=90,limit=5 ./sdc3/
btrfs balance start -dusage=99,limit=5 ./sdc3/
[Fri Jan 3 23:06:57 2025] BTRFS info (device sdc3): balance: start
-dusage=99,limit=5
[Fri Jan 3 23:06:57 2025] BTRFS info (device sdc3): relocating block
group 10938102710272 flags data
[Fri Jan 3 23:07:20 2025] BTRFS info (device sdc3): found 10 extents,
stage: move data extents
[Fri Jan 3 23:07:22 2025] BTRFS info (device sdc3): found 10 extents,
stage: update data pointers
[Fri Jan 3 23:07:22 2025] BTRFS info (device sdc3): relocating block
group 10937028968448 flags data
[Fri Jan 3 23:07:43 2025] BTRFS info (device sdc3): found 11 extents,
stage: move data extents
[Fri Jan 3 23:07:44 2025] BTRFS info (device sdc3): found 11 extents,
stage: update data pointers
[Fri Jan 3 23:07:45 2025] BTRFS info (device sdc3): relocating block
group 10935955226624 flags data
[Fri Jan 3 23:08:04 2025] BTRFS info (device sdc3): found 9 extents,
stage: move data extents
[Fri Jan 3 23:08:06 2025] BTRFS info (device sdc3): found 9 extents,
stage: update data pointers
btrfs balance start -musage=30,limit=5 ./sdc3/
btrfs balance start -musage=50,limit=5 ./sdc3/
btrfs balance start -musage=90,limit=5 ./sdc3/
btrfs balance start -musage=99,limit=5 ./sdc3/
What is strange with "musage"?
When I run with "musage" btrfs finds "24 extents" but for "system|dup".
[Fri Jan 3 22:30:59 2025] BTRFS info (device sdc3): balance: start
-musage=30,limit=1 -susage=30,limit=1
[Fri Jan 3 22:30:59 2025] BTRFS info (device sdc3): relocating block
group 10975113707520 flags system|dup
[Fri Jan 3 22:31:02 2025] BTRFS info (device sdc3): found 24 extents,
stage: move data extents
[Fri Jan 3 22:31:14 2025] BTRFS info (device sdc3): balance: ended with
status: 0
[Fri Jan 3 22:31:20 2025] BTRFS info (device sdc3): balance: start
-dusage=50,limit=1
[Fri Jan 3 22:31:20 2025] BTRFS info (device sdc3): relocating block
group 10975168233472 flags data
[Fri Jan 3 22:31:20 2025] BTRFS info (device sdc3): balance: ended with
status: 0
[Fri Jan 3 22:31:21 2025] BTRFS info (device sdc3): balance: start
-musage=50,limit=1 -susage=50,limit=1
[Fri Jan 3 22:31:21 2025] BTRFS info (device sdc3): relocating block
group 10975159844864 flags system|dup
[Fri Jan 3 22:31:26 2025] BTRFS info (device sdc3): found 24 extents,
stage: move data extents
[Fri Jan 3 22:31:28 2025] BTRFS info (device sdc3): balance: ended with
status: 0
Only sometimes there is "metadata|dup", and there is a huge (!!!) amount
of "found extents" — two thousand or four thousand:
[Fri Jan 3 18:09:49 2025] BTRFS info (device sdc3): balance: start
-musage=90,limit=3 -susage=90,limit=3
[Fri Jan 3 18:09:49 2025] BTRFS info (device sdc3): relocating block
group 10632086290432 flags metadata|dup
[Fri Jan 3 18:11:48 2025] BTRFS info (device sdc3): found 21714
extents, stage: move data extents
^^^
[Fri Jan 3 18:11:52 2025] BTRFS info (device sdc3): relocating block
group 2695122386944 flags metadata|dup
[Fri Jan 3 18:49:37 2025] BTRFS info (device sdc3): found 47432
extents, stage: move data extents
[Fri Jan 3 18:51:06 2025] BTRFS info (device sdc3): balance: ended with
status: 0
My command line is using only "musage":
btrfs balance start -musage=99,limit=1 ./sdc3/
but it optimizes "system|dup" and "metadata|dup".
[Fri Jan 3 21:52:55 2025] BTRFS info (device sdc3): balance: start
-musage=99,limit=1 -susage=99,limit=1
[Fri Jan 3 21:52:55 2025] BTRFS info (device sdc3): relocating block
group 10945618903040 flags system|dup
[Fri Jan 3 21:52:59 2025] BTRFS info (device sdc3): found 24 extents,
stage: move data extents
[Fri Jan 3 21:53:00 2025] BTRFS info (device sdc3): relocating block
group 10939176452096 flags metadata|dup
[Fri Jan 3 21:58:04 2025] BTRFS info (device sdc3): found 22488
extents, stage: move data extents
[Fri Jan 3 21:59:02 2025] BTRFS info (device sdc3): balance: ended with
status: 0
22488 found extents?
With musage=30:
[Fri Jan 3 22:54:35 2025] BTRFS info (device sdc3): balance: start
-musage=30,limit=1 -susage=30,limit=1
[Fri Jan 3 22:54:35 2025] BTRFS info (device sdc3): relocating block
group 10977475100672 flags metadata|dup
[Fri Jan 3 22:55:09 2025] BTRFS info (device sdc3): found 11710
extents, stage: move data extents
[Fri Jan 3 22:55:11 2025] BTRFS info (device sdc3): relocating block
group 10975306645504 flags system|dup
[Fri Jan 3 22:55:14 2025] BTRFS info (device sdc3): found 26 extents,
stage: move data extents
[Fri Jan 3 22:55:18 2025] BTRFS info (device sdc3): balance: ended with
status: 0
11710 found extents for musage=30?
I know, that standard solution is to
1. free space
2. make balance
But now I have 226GB free space, 92% disk occupied only, and only 19 Gb
of unallocated space.
How to reclaim unallocated space from that 226 GB free space?
next prev parent reply other threads:[~2025-01-03 22:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-14 17:55 97% full system, dusage didn't help, musage strange Leszek Dubiel
2024-12-14 18:35 ` Roman Mamedov
2024-12-14 18:47 ` Andrei Borzenkov
2024-12-14 20:13 ` Leszek Dubiel
2024-12-14 21:14 ` Qu Wenruo
2024-12-16 17:12 ` Leszek Dubiel
2024-12-16 21:01 ` Qu Wenruo
2024-12-17 21:44 ` Leszek Dubiel
2025-01-03 22:52 ` Leszek Dubiel [this message]
2025-01-04 5:32 ` Andrei Borzenkov
2025-01-04 7:11 ` Leszek Dubiel
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=000bcef0-a86e-4832-90bb-9a4a47afad6d@dubiel.pl \
--to=leszek@dubiel.pl \
--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