All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: gregkh@linuxfoundation.org
Cc: josef@toxicpanda.com, dsterba@suse.com, martin@lichtvoll.de,
	wqu@suse.com, stable@vger.kernel.org
Subject: Re: FAILED: patch "[PATCH] btrfs: do not zero f_bavail if we have available space" failed to apply to 5.4-stable tree
Date: Sun, 9 Feb 2020 12:44:51 -0500	[thread overview]
Message-ID: <20200209174451.GH3584@sasha-vm> (raw)
In-Reply-To: <158124801318473@kroah.com>

On Sun, Feb 09, 2020 at 12:33:33PM +0100, gregkh@linuxfoundation.org wrote:
>
>The patch below does not apply to the 5.4-stable tree.
>If someone wants it applied there, or to any other stable or longterm
>tree, then please email the backport, including the original git commit
>id to <stable@vger.kernel.org>.
>
>thanks,
>
>greg k-h
>
>------------------ original commit in Linus's tree ------------------
>
>From d55966c4279bfc6a0cf0b32bf13f5df228a1eeb6 Mon Sep 17 00:00:00 2001
>From: Josef Bacik <josef@toxicpanda.com>
>Date: Fri, 31 Jan 2020 09:31:05 -0500
>Subject: [PATCH] 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>

This one is queued up already :)

-- 
Thanks,
Sasha

      reply	other threads:[~2020-02-09 17:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-09 11:33 FAILED: patch "[PATCH] btrfs: do not zero f_bavail if we have available space" failed to apply to 5.4-stable tree gregkh
2020-02-09 17:44 ` Sasha Levin [this message]

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=20200209174451.GH3584@sasha-vm \
    --to=sashal@kernel.org \
    --cc=dsterba@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=josef@toxicpanda.com \
    --cc=martin@lichtvoll.de \
    --cc=stable@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.