]> git.baikalelectronics.ru Git - kernel.git/commit
btrfs: do not zero f_bavail if we have available space
authorJosef Bacik <josef@toxicpanda.com>
Fri, 31 Jan 2020 14:31:05 +0000 (09:31 -0500)
committerDavid Sterba <dsterba@suse.com>
Sun, 2 Feb 2020 17:49:32 +0000 (18:49 +0100)
commit60c947991398feb0e71f43d48609d496f4483209
treedc1a9fe91dc71262791e699d4f253656637eeaa7
parent63c9e37756c908ccb4ba4f5057bb4364f2d8a61f
btrfs: do not zero f_bavail if we have available space

There was some logic added a while ago to clear out f_bavail in statfs()
if we did not have enough free metadata space to satisfy our global
reserve.  This was incorrect at the time, however didn't really pose a
problem for normal file systems because we would often allocate chunks
if we got this low on free metadata space, and thus wouldn't really hit
this case unless we were actually full.

Fast forward to today and now we are much better about not allocating
metadata chunks all of the time.  Couple this with 1afcbdfebfe2 ("btrfs:
always reserve our entire size for the global reserve") which now means
we'll easily have a larger global reserve than our free space, we are
now more likely to trip over this while still having plenty of space.

Fix this by skipping this logic if the global rsv's space_info is not
full.  space_info->full is 0 unless we've attempted to allocate a chunk
for that space_info and that has failed.  If this happens then the space
for the global reserve is definitely sacred and we need to report
b_avail == 0, but before then we can just use our calculated b_avail.

Reported-by: Martin Steigerwald <martin@lichtvoll.de>
Fixes: a13f2c095e4b ("btrfs: statfs: report zero available if metadata are exhausted")
CC: stable@vger.kernel.org # 4.5+
Reviewed-by: Qu Wenruo <wqu@suse.com>
Tested-By: Martin Steigerwald <martin@lichtvoll.de>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/super.c