Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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?














  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