Linux-BTRFS Archive on
 help / color / Atom feed
From: David Sterba <>
To: Qu Wenruo <>
Subject: Re: [PATCH] btrfs: statfs: Don't reset f_bavail if we're over committing metadata space
Date: Thu, 16 Jan 2020 15:29:28 +0100
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Jan 15, 2020 at 11:41:28AM +0800, Qu Wenruo wrote:
> [BUG]
> When there are a lot of metadata space reserved, e.g. after balancing a
> data block with many extents, vanilla df would report 0 available space.
> btrfs_statfs() would report 0 available space if its metadata space is
> exhausted.
> And the calculation is based on currently reserved space vs on-disk
> available space, with a small headroom as buffer.
> When there is not enough headroom, btrfs_statfs() will report 0
> available space.
> The problem is, since commit ef1317a1b9a3 ("btrfs: do not allow
> reservations if we have pending tickets"), we allow btrfs to over commit
> metadata space, as long as we have enough space to allocate new metadata
> chunks.
> This makes old calculation unreliable and report false 0 available space.
> [FIX]
> Don't do such naive check anymore for btrfs_statfs().
> Also remove the comment about "0 available space when metadata is
> exhausted".

This is intentional and was added to prevent a situation where 'df'
reports available space but exhausted metadata don't allow to create new

If it gets removed you are trading one bug for another. With the changed
logic in the referenced commit, the metadata exhaustion is more likely
but it's also temporary.

The overcommit and overestimated reservations make it hard if not
impossible to do any accurate calculation in statfs/df. From the
usability side, there are 2 options:

a) return 0 free, while it's still possible to eg. create files
b) return >0 free, but no new file can be created

The user report I got was for b) so that's what the guesswork fixes and
does a). The idea behind that is that there's really low space, but with
the overreservation caused by balance it's not.

I don't see a good way out of that which could be solved inside statfs,
it only interprets the numbers in the best way under circumstances. We
don't have exact reservation, don't have a delta of the
reserved-requested (to check how much the reservation is off).

  parent reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15  3:41 Qu Wenruo
2020-01-15 11:40 ` Qu WenRuo
2020-01-16 14:29 ` David Sterba [this message]
2020-01-17  0:54   ` Qu Wenruo
2020-01-17  1:32     ` Qu Wenruo
2020-01-17 14:10       ` David Sterba
2020-01-17 14:22         ` Qu Wenruo
2020-01-29 15:38           ` David Sterba
2020-01-17 14:02     ` David Sterba
2020-01-17 14:16       ` Qu Wenruo
2020-01-29 16:01         ` David Sterba

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-BTRFS Archive on

Archives are clonable:
	git clone --mirror linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ \
	public-inbox-index linux-btrfs

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone