All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: "Lentes, Bernd" <bernd.lentes@helmholtz-muenchen.de>,
	Btrfs ML <linux-btrfs@vger.kernel.org>
Subject: Re: some principal questions to "disk full"
Date: Wed, 26 May 2021 08:36:00 +0300	[thread overview]
Message-ID: <2c00a97f-ac79-147c-ddd2-7ff4a90ca941@gmail.com> (raw)
In-Reply-To: <1771321158.76542899.1621959622455.JavaMail.zimbra@helmholtz-muenchen.de>

On 25.05.2021 19:20, Lentes, Bernd wrote:
> Hi guys,
> 
> it would be great if you can help me to sort out my understanding of BTRFS and its problems with "disk full".
> I'm using BTRFS on several systems and this is now the first time that i have a "full disk".
> I'd really like to understand the problem and also how to solve it.
> I gave my best to read and understand https://btrfs.wiki.kernel.org/index.php/FAQ.
> 
> My setup:
> Ubuntu 18.04
> kernel 4.4.0-66-generic
> 64 bit
> 
> My disk:
> root@pc65472:/data# btrfs fi show /
> Label: none  uuid: 3a623645-a5e1-438e-b0f3-f02520f1a2eb
>         Total devices 2 FS bytes used 350.08GiB
>         devid    1 size 420.00GiB used 420.00GiB path /dev/mapper/vg1-lv_root
>         devid    2 size 2.00GiB used 1.00GiB path /dev/loop0
> (the loop device is from an effort of "btrfs balance" i will report later on).
> 
> Is it correct that the 420GiB shown as "used" in the line of devid 1 means "allocated" ?

Yes

> Allocated means ... "not usable, reserved" ?

btrfs is using two stage space management. First large areas (chunk,
block group) are allocated on device, then each chunk is subdivided in
extents as needed. You have 420iGB of block groups and inside of these
block groups 350,08GiB was used by actual data.

> What is "unallocated" ? A kind of "free, usable" ?
> 

Device space not belonging to any block group. Yes, it is "free,
usable", but so are 69.92GiB inside of allocated space.

> root@pc65472:/data# btrfs fi usage /
> Overall:
>     Device size:                 422.00GiB
>     Device allocated:            421.00GiB
>     Device unallocated:            1.00GiB
>     Device missing:                  0.00B
>     Used:                        350.08GiB
>     Free (estimated):             70.29GiB      (min: 70.29GiB)

Which is what it tells you - it is sum of unallocated space and unused
allocated space.

>     Data ratio:                       1.00
>     Metadata ratio:                   1.00
>     Global reserve:              512.00MiB      (used: 0.00B)
> 
> Data,single: Size:413.99GiB, Used:344.69GiB
>    /dev/mapper/vg1-lv_root       413.99GiB
> 
> Metadata,single: Size:7.01GiB, Used:5.39GiB
>    /dev/loop0      1.00GiB
>    /dev/mapper/vg1-lv_root         6.01GiB
> 
> System,single: Size:4.00MiB, Used:80.00KiB
>    /dev/mapper/vg1-lv_root         4.00MiB
> 
> Unallocated:
>    /dev/loop0      1.00GiB
>    /dev/mapper/vg1-lv_root           0.00B
> 
> "Device size" and "Device allocated" is slight bigger than shown with "btrfs fi show"

Both show exactly the same 422GiB and 421GiB.

> It seems the output of "btrfs usage /" adds the loop-device in its calculation, and "btrfs fi show" doesn't. Correct ?

No.

> 
> I think the reason for "disk full" is the metadata:
> Metadata,single: Size:7.01GiB, Used:5.39GiB
>    /dev/loop0      1.00GiB
>    /dev/mapper/vg1-lv_root         6.01GiB
> 
> Before i added the loop nearly all space for the metadata was occupied (5,4GiB from 6GiB). That's the problem ?

It depends, but in general everything btrfs does requires allocation of
additional metadata to complete the operation. You are certainly very
low on available metadata space.

> Only 600MB were free for metadata, that's roundabout the "Global Reserve", and that's, following the wiki, to little.
> 
> I deleted som old snapshots and now have enough space. I started a "btrfs balance".
> My first effort with an additional device (the loop device) didn't suceed.
> 

Showing actual logs with actual error is better than giving vague
description.

> What can i do to prevent a "disk full" situation ?

The only universal answer - do not fill up your disk. Seriously.

> Running regulary "btrfs balance" in a cron job ?
> 

If you are using more or less recent kernel version, you need not run
btrfs balance at all except when possibly converting profiles or adding
new device. btrfs became reasonably good at managing free space.

> Is there a way to transform allocated space to unallocated space ?
> 

Only by using balance. But that requires sufficient free space to
allocate additional metadata during balance.

Normally btrfs is using different space to store data and metadata. So
even if you have 60GiB of free space inside data block groups, it cannot
be used to allocate metadata.

You can try running "btrfs balance start -d usage=0" - it does not move
any data, just removes completely empty block groups. Also running
balance with small usage (like 1 to 5) percentage may help in compacting
block groups.

Running full balance should certainly be avoided.

  reply	other threads:[~2021-05-26  5:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25 16:20 some principal questions to "disk full" Lentes, Bernd
2021-05-26  5:36 ` Andrei Borzenkov [this message]
2021-05-26  9:41   ` Lentes, Bernd
2021-05-28 19:51     ` Zygo Blaxell

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=2c00a97f-ac79-147c-ddd2-7ff4a90ca941@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=bernd.lentes@helmholtz-muenchen.de \
    --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.