All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: Nikolay Borisov <nborisov@suse.com>
Cc: Wolf <wolf@wolfsden.cz>, linux-btrfs@vger.kernel.org
Subject: Re: Healthy amount of free space?
Date: Tue, 17 Jul 2018 10:02:03 +0200	[thread overview]
Message-ID: <2197534.TZSffJRfLT@merkaba> (raw)
In-Reply-To: <1dd72720-1beb-a5e6-5bd4-88d6af5f02bd@suse.com>

Hi Nikolay.

Nikolay Borisov - 17.07.18, 09:20:
> On 16.07.2018 23:58, Wolf wrote:
> > Greetings,
> > I would like to ask what what is healthy amount of free space to
> > keep on each device for btrfs to be happy?
> > 
> > This is how my disk array currently looks like
> > 
> >     [root@dennas ~]# btrfs fi usage /raid
> >     
> >     Overall:
> >         Device size:                  29.11TiB
> >         Device allocated:             21.26TiB
> >         Device unallocated:            7.85TiB
> >         Device missing:                  0.00B
> >         Used:                         21.18TiB
> >         Free (estimated):              3.96TiB      (min: 3.96TiB)
> >         Data ratio:                       2.00
> >         Metadata ratio:                   2.00
> >         Global reserve:              512.00MiB      (used: 0.00B)
[…]
> > Btrfs does quite good job of evenly using space on all devices. No,
> > how low can I let that go? In other words, with how much space
> > free/unallocated remaining space should I consider adding new disk?
> 
> Btrfs will start running into problems when you run out of unallocated
> space. So the best advice will be monitor your device unallocated,
> once it gets really low - like 2-3 gb I will suggest you run balance
> which will try to free up unallocated space by rewriting data more
> compactly into sparsely populated block groups. If after running
> balance you haven't really freed any space then you should consider
> adding a new drive and running balance to even out the spread of
> data/metadata.

What are these issues exactly?

I have

% btrfs fi us -T /home
Overall:
    Device size:                 340.00GiB
    Device allocated:            340.00GiB
    Device unallocated:            2.00MiB
    Device missing:                  0.00B
    Used:                        308.37GiB
    Free (estimated):             14.65GiB      (min: 14.65GiB)
    Data ratio:                       2.00
    Metadata ratio:                   2.00
    Global reserve:              512.00MiB      (used: 0.00B)

                          Data      Metadata System              
Id Path                   RAID1     RAID1    RAID1    Unallocated
-- ---------------------- --------- -------- -------- -----------
 1 /dev/mapper/msata-home 165.89GiB  4.08GiB 32.00MiB     1.00MiB
 2 /dev/mapper/sata-home  165.89GiB  4.08GiB 32.00MiB     1.00MiB
-- ---------------------- --------- -------- -------- -----------
   Total                  165.89GiB  4.08GiB 32.00MiB     2.00MiB
   Used                   151.24GiB  2.95GiB 48.00KiB

on a RAID-1 filesystem one, part of the time two Plasma desktops + 
KDEPIM and Akonadi + Baloo desktop search + you name it write to like 
mad.

Since kernel 4.5 or 4.6 this simply works. Before that sometimes BTRFS 
crawled to an halt on searching for free blocks, and I had to switch off 
the laptop uncleanly. If that happened, a balance helped for a while. 
But since 4.5 or 4.6 this did not happen anymore.

I found with SLES 12 SP 3 or so there is btrfsmaintenance running a 
balance weekly. Which created an issue on our Proxmox + Ceph on Intel 
NUC based opensource demo lab. This is for sure no recommended 
configuration for Ceph and Ceph is quite slow on these 2,5 inch 
harddisks and 1 GBit network link, despite albeit somewhat minimal, 
limited to 5 GiB m.2 SSD caching. What happened it that the VM crawled 
to a halt and the kernel gave task hung for more than 120 seconds 
messages. The VM was basically unusable during the balance. Sure that 
should not happen with a "proper" setup, also it also did not happen 
without the automatic balance.

Also what would happen on a hypervisor setup with several thousands of 
VMs with BTRFS, when several 100 of them decide to start the balance at 
a similar time? It could probably bring the I/O system below to an halt, 
as many enterprise storage systems are designed to sustain burst I/O 
loads, but not maximum utilization during an extended period of time.

I am really wondering what to recommend in my Linux performance tuning 
and analysis courses. On my own laptop I do not do regular balances so 
far. Due to my thinking: If it is not broken, do not fix it.

My personal opinion here also is: If the filesystem degrades that much 
that it becomes unusable without regular maintenance from user space, 
the filesystem needs to be fixed. Ideally I would not have to worry on 
whether to regularly balance an BTRFS or not. In other words: I should 
not have to visit a performance analysis and tuning course in order to 
use a computer with BTRFS filesystem.

Thanks,
-- 
Martin



  reply	other threads:[~2018-07-17  8:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-16 20:58 Healthy amount of free space? Wolf
2018-07-17  7:20 ` Nikolay Borisov
2018-07-17  8:02   ` Martin Steigerwald [this message]
2018-07-17  8:16     ` Nikolay Borisov
2018-07-17 17:54       ` Martin Steigerwald
2018-07-18 12:35         ` Austin S. Hemmelgarn
2018-07-18 13:07           ` Chris Murphy
2018-07-18 13:30             ` Austin S. Hemmelgarn
2018-07-18 17:04               ` Chris Murphy
2018-07-18 17:06                 ` Austin S. Hemmelgarn
2018-07-18 17:14                   ` Chris Murphy
2018-07-18 17:40                     ` Chris Murphy
2018-07-18 18:01                       ` Austin S. Hemmelgarn
2018-07-18 21:32                         ` Chris Murphy
2018-07-18 21:47                           ` Chris Murphy
2018-07-19 11:21                           ` Austin S. Hemmelgarn
2018-07-20  5:01               ` Andrei Borzenkov
2018-07-20 11:36                 ` Austin S. Hemmelgarn
2018-07-17 11:46 ` Austin S. Hemmelgarn

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=2197534.TZSffJRfLT@merkaba \
    --to=martin@lichtvoll.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=wolf@wolfsden.cz \
    /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.