All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Gelmini <andrea.gelmini@gmail.com>
To: brandonh@wolfram.com
Cc: Linux BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs metadata has reserved 1T of extra space and balances don't reclaim it
Date: Wed, 29 Sep 2021 17:18:05 +0200	[thread overview]
Message-ID: <CAK-xaQYo1vRi10ZY09q2=7oCTPy1s_i8-rZV_vyc0AMX1JOQLQ@mail.gmail.com> (raw)
In-Reply-To: <70668781.1658599.1632882181840.JavaMail.zimbra@wolfram.com>

Il giorno mer 29 set 2021 alle ore 04:41 Brandon Heisner
<brandonh@wolfram.com> ha scritto:
>
> I have a server running CentOS 7 on 4.9.5-1.el7.elrepo.x86_64 #1 SMP Fri Jan 20 11:34:13 EST 2017 x86_64 x86_64 x86_64 GNU/Linux.  It is version locked to that kernel.  The metadata has reserved a full 1T of disk space, while only using ~38G.  I've tried to balance the metadata to reclaim that so it can be used for data, but it doesn't work and gives no errors.  It just says it balanced the chunks but the size doesn't change.  The metadata total is still growing as well, as it used to be 1.04 and now it is 1.08 with only about 10G more of metadata used.  I've tried doing balances up to 70 or 80 musage I think, and

Similar situation here.
A 18TB single disk with one big snapraid parity file, and a lot of
metadata allocated.
I solved with:
btrfs filesystem defrag -v -r -clzo  . (useless the compression, in my case)

So, just after a little bit from start  I saw already space reclaming.

In the end I fallback to exfat to avoid to keep re-reading/re-writing
all data just to avoid "metadata waste".

Ciao,
Gelma

  parent reply	other threads:[~2021-09-29 15:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29  2:23 btrfs metadata has reserved 1T of extra space and balances don't reclaim it Brandon Heisner
2021-09-29  7:23 ` Forza
2021-09-29 14:34   ` Brandon Heisner
2021-10-03 11:26     ` Forza
2021-10-03 18:21       ` Zygo Blaxell
2021-09-29  8:22 ` Qu Wenruo
2021-09-29 15:18 ` Andrea Gelmini [this message]
2021-09-29 16:39   ` Forza
2021-09-29 18:55     ` Andrea Gelmini
2021-09-29 17:31 ` Zygo Blaxell
2021-10-01  7:49   ` Brandon Heisner

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='CAK-xaQYo1vRi10ZY09q2=7oCTPy1s_i8-rZV_vyc0AMX1JOQLQ@mail.gmail.com' \
    --to=andrea.gelmini@gmail.com \
    --cc=brandonh@wolfram.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.