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



  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