Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Leszek Dubiel <leszek@dubiel.pl>,
	Andrei Borzenkov <arvidjaar@gmail.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: 97% full system, dusage didn't help, musage strange
Date: Sun, 15 Dec 2024 07:44:01 +1030	[thread overview]
Message-ID: <8eb9e55e-7a61-4c1a-b5ab-acf35ba4396e@gmx.com> (raw)
In-Reply-To: <4144f14a-8742-4092-b558-d1a9de4d03e5@dubiel.pl>



在 2024/12/15 06:43, Leszek Dubiel 写道:
>>
>>
>> btrfs filesystem usage -T
>>
>
> Overall:
>      Device size:          16.28TiB
>      Device allocated:          16.24TiB
>      Device unallocated:          38.02GiB
>      Device missing:             0.00B
>      Device slack:             0.00B
>      Used:              15.75TiB
>      Free (estimated):         264.00GiB    (min: 264.00GiB)
>      Free (statfs, df):         257.98GiB
>      Data ratio:                  2.00
>      Metadata ratio:              2.00
>      Global reserve:         512.00MiB    (used: 160.00KiB)
>      Multiple profiles:                no
>
>               Data    Metadata System
> Id Path      RAID1   RAID1    RAID1    Unallocated Total    Slack
> -- --------- ------- -------- -------- ----------- -------- -----
>   1 /dev/sdb2 5.39TiB 28.00GiB 32.00MiB    13.00GiB  5.43TiB     -
>   2 /dev/sdc2 5.39TiB 20.00GiB        -    13.03GiB  5.43TiB     -
>   3 /dev/sda3 5.38TiB 34.00GiB 32.00MiB    12.00GiB  5.43TiB     -
> -- --------- ------- -------- -------- ----------- -------- -----
>     Total     8.08TiB 41.00GiB 32.00MiB    38.02GiB 16.28TiB 0.00B
>     Used      7.84TiB 37.67GiB  1.47MiB
>
>
>
>>>
>>> But unallocated space didn't increase.
>>>
>>>
>>
>> Why did you expect it to increase? To free space balance need to pack
>> more extents into less chunks. In your case chunks are near to full
>> and extents are relatively large, so chunks simply may not have enough
>> free space to accommodate more extents. You just move extents around.
>>
>
> Ok. I didn't exactly know what chunks are compared to extents.
>
>
>
>
>
>> Relocating one chunk simply moves extents from this chunk to another
>> location. It does not free any chunk. You can only get more
>> unallocated space when you are able to pack extents from two (or more)
>> chunks into one chunk. Which is only possible if chunks are filled to
>> 50%.
>>
>
> Thank you for explanation.
>
>
>
>
>>> What should i do next?
>>
>> It looks like your filesystem is simply full. Do you have reasons to
>> believe that it is not true?
>
>
> It is backup server. It should be almost full.
> I have a procedure that:
>
> — removes old snapshots if free space is less then 250 GB
> — starts balancing if there is less then 8GB of unallocated space on any
> disk
>
>
> It failed now — there is 258 GB free, but balancing didn't help to
> restore unallocated space.

Because there isn't that much free space to reclaim in the first place.

Your data and metadata chunks are already very highly utilized, you can
increase the dusage/musage and retry, but they will only bring marginal
gain if any.

The only way to go next is start deleting more
snapshots/subvolumes/files/etc.

With more data/metadata space released, then try musage/dusage again
which can free up some space.

Thanks,
Qu

  reply	other threads:[~2024-12-14 21:14 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 [this message]
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
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=8eb9e55e-7a61-4c1a-b5ab-acf35ba4396e@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=arvidjaar@gmail.com \
    --cc=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