From: Martin Steigerwald <martin@lichtvoll.de>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Cc: waxhead@dirtcellar.net
Subject: Re: Never balance metadata?
Date: Sat, 11 Feb 2023 09:38:18 +0100 [thread overview]
Message-ID: <1755726.VLH7GnMWUR@lichtvoll.de> (raw)
In-Reply-To: <ad4de975-3d5f-4dbb-45a5-795626c53c61@dirtcellar.net>
waxhead - 11.02.23, 02:36:26 CET:
> I have read several places, including on this mailing list that
> metadata is not supposed to be balanced unless converting between
> profiles.
>
> Interestingly enough there is nothing mentioned about this in the
> docs... https://btrfs.readthedocs.io/en/latest/btrfs-balance.html
>
> Should one still NOT balance metadata? If so - please update the docs
> with a explanation to why one should not do that.
If that is still the case, it may also be good to by default omit
metadata on a balance without parameters.
A long, long time ago I experienced a much longer boot time after a
balance, I decided to refrain from balancing my BTRFS file systems.
Especially as long as there is still unallocated space on them. Cause as
long as BTRFS can still allocate a chunk, I thought that is fine. I
thought I would be getting a faster system, but it was much much slower.
That was on a SATA SSD.
An additional reason for not, or at least not regularly balancing for me
is avoiding needless writes to flash storage like SATA or NVMe SSDs.
Usually they can take it, but why age them more than needed?
Maybe all or some of this is not accurate anymore and one should balance
BTRFS regularly like default in SUSE distributions, maybe regular
balancing even reduces writes on other occasions, however I never fully
understood the performance impact of a regular balance. However in a
virtual environment with lots of virtual machines it may not be best to
start balance on a lot of them at same or similar times either,
considering the load it creates for the underlying storage.
I know balancing not the same as defragmenting files in other filesystems,
but I still remember the strong warnings of XFS developers not to ever
just defragment a XFS filesystem just cause you feel like it. The
reasoning behind these warnings was that defragmenting files tends to
fragment free space. But balancing actually defragments free space as
far as I understood and thus is different.
Anyway, I am keen to read on more insight on this from people who
understand better what impact a BTRFS balance really has.
Thanks,
--
Martin
next prev parent reply other threads:[~2023-02-11 8:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-11 1:36 Never balance metadata? waxhead
2023-02-11 8:38 ` Martin Steigerwald [this message]
2023-02-11 11:42 ` Andrei Borzenkov
2023-02-11 13:25 ` Martin Steigerwald
2023-02-12 10:10 ` Jukka Larja
2023-02-17 3:19 ` Zygo Blaxell
2023-02-11 17:18 ` Forza
2023-02-11 19:50 ` Martin Steigerwald
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=1755726.VLH7GnMWUR@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=waxhead@dirtcellar.net \
/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