summaryrefslogtreecommitdiff
path: root/fs/Makefile
diff options
context:
space:
mode:
authorJosef Bacik <josef@toxicpanda.com>2020-01-31 09:31:05 -0500
committerDavid Sterba <dsterba@suse.com>2020-02-02 18:49:32 +0100
commitd55966c4279bfc6a0cf0b32bf13f5df228a1eeb6 (patch)
treedc1a9fe91dc71262791e699d4f253656637eeaa7 /fs/Makefile
parent9722b10148504c4153a74a9c89725af271e490fc (diff)
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 d792b0f19711 ("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: ca8a51b3a979 ("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>
Diffstat (limited to 'fs/Makefile')
0 files changed, 0 insertions, 0 deletions