Marc MERLIN - 19.02.20, 01:42:57 CET:
> Has the patch gotten to any 5.5 release too?
Yes, as git log easily reveals.
> On Sun, Feb 2, 2020, 12:53 David Sterba <dsterba@xxxxxxx> wrote:
> > On Fri, Jan 31, 2020 at 09:31:05AM -0500, Josef Bacik wrote:
> > > 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
> > > 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.
> > >
> > > There are other cases where df isn't quite right, and Qu is
> > > addressing them in a more holistic way. This simply fixes the
> > > users that are currently experiencing pain because of this
> > > problem.
> > >
> > > Fixes: ca8a51b3a979 ("btrfs: statfs: report zero available if
> > > metadata>
> > are exhausted")
> >
> > > Reported-by: Martin Steigerwald <martin@xxxxxxxxxxxx>
> > > Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
> >
> > Added to 5.6 queue, thanks.
--
Martin
