From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Forza <forza@tnonline.net>
Cc: brandonh@wolfram.com, linux-btrfs@vger.kernel.org
Subject: Re: btrfs metadata has reserved 1T of extra space and balances don't reclaim it
Date: Sun, 3 Oct 2021 14:21:48 -0400 [thread overview]
Message-ID: <20211003182148.GP29026@hungrycats.org> (raw)
In-Reply-To: <cda76e1b-b98a-4b13-19b1-2cf6ea8b4cf4@tnonline.net>
On Sun, Oct 03, 2021 at 01:26:24PM +0200, Forza wrote:
>
>
> On 2021-09-29 16:34, Brandon Heisner wrote:
> > No I do not use that option. Also, because of btrfs not mounting individual subvolume options, I have the compression and nodatacow set with filesystem attributes on the directories that are btrfs subvolumes.
> >
> > UUID=ece150db-5817-4704-9e84-80f7d8a3b1da /opt/zimbra btrfs subvol=zimbra,defaults,discard,compress=lzo 0 0
> > UUID=ece150db-5817-4704-9e84-80f7d8a3b1da /var/log btrfs subvol=root-var-log,defaults,discard,compress=lzo 0 0
> > UUID=ece150db-5817-4704-9e84-80f7d8a3b1da /opt/zimbra/db btrfs subvol=db,defaults,discard,nodatacow 0 0
> > UUID=ece150db-5817-4704-9e84-80f7d8a3b1da /opt/zimbra/index btrfs subvol=index,defaults,discard,compress=lzo 0 0
> > UUID=ece150db-5817-4704-9e84-80f7d8a3b1da /opt/zimbra/store btrfs subvol=store,defaults,discard,compress=lzo 0 0
> > UUID=ece150db-5817-4704-9e84-80f7d8a3b1da /opt/zimbra/log btrfs subvol=log,defaults,discard,compress=lzo 0 0
> > UUID=ece150db-5817-4704-9e84-80f7d8a3b1da /opt/zimbra/snapshots btrfs subvol=snapshots,defaults,discard,compress=lzo 0 0
> >
> >
>
> It might be worth looking into discard=async (*) or setting up regular
> fstrim instead of doing the discard mount option.
Brandon's kernel (4.9.5 from 2017) is three years too old to have working
discard=async.
Upgrading the kernel would most likely fix the problems even without
changing mount options.
> * async discard:
> "mount -o discard=async" to enable it freed extents are not discarded
> immediatelly, but grouped together and trimmed later, with IO rate limiting
> * https://lore.kernel.org/lkml/cover.1580142284.git.dsterba@suse.com/
next prev parent reply other threads:[~2021-10-03 18:21 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 [this message]
2021-09-29 8:22 ` Qu Wenruo
2021-09-29 15:18 ` Andrea Gelmini
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=20211003182148.GP29026@hungrycats.org \
--to=ce3g8jdj@umail.furryterror.org \
--cc=brandonh@wolfram.com \
--cc=forza@tnonline.net \
--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