From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: dsterba@suse.cz, Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: statfs: Don't reset f_bavail if we're over committing metadata space
Date: Fri, 17 Jan 2020 15:02:31 +0100 [thread overview]
Message-ID: <20200117140231.GF3929@twin.jikos.cz> (raw)
In-Reply-To: <40ff2d8d-eb3b-1c90-ea19-618e5c058bcc@gmx.com>
On Fri, Jan 17, 2020 at 08:54:35AM +0800, Qu Wenruo wrote:
>
>
> On 2020/1/16 下午10:29, David Sterba wrote:
> > 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.
> >>
> >> [CAUSE]
> >> 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
> > inode.
>
> But this behavior itself is not accurate.
>
> We have global reservation, which is normally always larger than the
> immediate number 4M.
The global block reserve is subtracted from the metadata accounted from
the block groups. And after that, if there's only little space left, the
check triggers. Because at this point any new metadata reservation
cannot be satisfied from the remaining space, yet there's >0 reported.
> So that check will never really be triggered.
>
> Thus invalidating most of your argument.
Please read the current comment and code in statfs again.
next prev parent reply other threads:[~2020-01-17 14:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 3:41 [PATCH] btrfs: statfs: Don't reset f_bavail if we're over committing metadata space Qu Wenruo
2020-01-15 11:40 ` Qu WenRuo
2020-01-16 14:29 ` David Sterba
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 [this message]
2020-01-17 14:16 ` Qu Wenruo
2020-01-29 16:01 ` David Sterba
2020-01-31 2:23 ` Zygo Blaxell
2020-01-30 21:05 ` Josef Bacik
2020-01-30 23:14 ` Anand Jain
2020-01-31 0:35 ` Qu Wenruo
2020-01-31 11:58 ` Qu Wenruo
2020-01-31 12:34 ` David Sterba
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=20200117140231.GF3929@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.com \
/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;
as well as URLs for NNTP newsgroup(s).