public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Martin Steigerwald <martin@lichtvoll.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Understanding "Used" in df
Date: Thu, 23 Jul 2020 00:51:06 -0400	[thread overview]
Message-ID: <20200723045106.GL10769@hungrycats.org> (raw)
In-Reply-To: <3225288.0drLW0cIUP@merkaba>

On Wed, Jul 22, 2020 at 05:10:19PM +0200, Martin Steigerwald wrote:
> I have:
> 
> % LANG=en df -hT /home
> Filesystem            Type   Size  Used Avail Use% Mounted on
> /dev/mapper/sata-home btrfs  300G  175G  123G  59% /home
> 
> And:
> 
> merkaba:~> btrfs fi sh /home   
> Label: 'home'  uuid: […]
>         Total devices 2 FS bytes used 173.91GiB
>         devid    1 size 300.00GiB used 223.03GiB path /dev/mapper/sata-home
>         devid    2 size 300.00GiB used 223.03GiB path /dev/mapper/msata-home
> 
> merkaba:~> btrfs fi df /home
> Data, RAID1: total=218.00GiB, used=171.98GiB
> System, RAID1: total=32.00MiB, used=64.00KiB
> Metadata, RAID1: total=5.00GiB, used=1.94GiB
> GlobalReserve, single: total=490.48MiB, used=0.00B
> 
> As well as:
> 
> merkaba:~> btrfs fi usage -T /home
> Overall:
>     Device size:                 600.00GiB
>     Device allocated:            446.06GiB
>     Device unallocated:          153.94GiB
>     Device missing:                  0.00B
>     Used:                        347.82GiB
>     Free (estimated):            123.00GiB      (min: 123.00GiB)
>     Data ratio:                       2.00
>     Metadata ratio:                   2.00
>     Global reserve:              490.45MiB      (used: 0.00B)
>     Multiple profiles:                  no
> 
>                           Data      Metadata System              
> Id Path                   RAID1     RAID1    RAID1    Unallocated
> -- ---------------------- --------- -------- -------- -----------
>  1 /dev/mapper/sata-home  218.00GiB  5.00GiB 32.00MiB    76.97GiB
>  2 /dev/mapper/msata-home 218.00GiB  5.00GiB 32.00MiB    76.97GiB
> -- ---------------------- --------- -------- -------- -----------
>    Total                  218.00GiB  5.00GiB 32.00MiB   153.94GiB
>    Used                   171.97GiB  1.94GiB 64.00KiB   
> 
> 
> I think I understand all of it, including just 123G instead of
> 300 - 175 = 125 GiB "Avail" in df -hT.
> 
> But why 175 GiB "Used" in 'df -hT' when just 173.91GiB (see 'btrfs fi sh')
> is allocated *within* the block group / chunks?

statvfs (the 'df' syscall) does not report a "used" number, only total
and available btrfs data blocks (no metadata blocks are counted).
'df' computes "used" by subtracting f_blocks - f_bavail.

	122.99875 = 300 - 171.97 - 5 - .03125

	df_free = total - data_used - metadata_allocated - system_allocated

Inline files count as metadata instead of data, so even when you are
out of data blocks (zero blocks free in df), you can sometimes still
write small files.  Sometimes, when you write one small file, 1GB of
available space disappears as a new metadata block group is allocated.

'df' doesn't take metadata or data sharing into account at all, or
the space required to store csums, or bursty metadata usage workloads.
'df' can't predict these events, so its accuracy is limited to no better
than about 0.5% of the size of the filesystem or +/- 1GB, whichever is
larger.

> Does this have something to do with that global reserve thing?

'df' currently tells you nothing about metadata (except in kernels
before 5.6, when you run too low on metadata space, f_bavail is abruptly
set to zero).  That's about the only impact global reserve has on 'df'.

Global reserve is metadata allocated-but-unused space, and all metadata
is not visible to df.  The reserve ensures that critical btrfs metadata
operations can complete without running out of space, by forcing
non-critical long-running operations to commit transactions when no
metadata space is available outside the reserved pool.  It mostly works,
though there are still a few bugs left that lead to EROFS when metadata
runs low.

> 
> Thank you,
> -- 
> Martin
> 
> 

  parent reply	other threads:[~2020-07-23  4:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22 15:10 Understanding "Used" in df Martin Steigerwald
2020-07-22 19:07 ` A L
2020-07-23  4:51 ` Zygo Blaxell [this message]
2020-07-27 11:38   ` Martin Steigerwald
2020-07-27 16:42     ` Andrei Borzenkov
2020-07-27 19:30       ` Chris Murphy
2020-07-27 19:48         ` Andrei Borzenkov
2020-07-27 20:47           ` Hugo Mills
2020-07-28 21:20     ` 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=20200723045106.GL10769@hungrycats.org \
    --to=ce3g8jdj@umail.furryterror.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=martin@lichtvoll.de \
    /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