From: Josef Bacik <josef@toxicpanda.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 3/5] btrfs: only take normal tickets into account in may_commit_transaction
Date: Mon, 9 Mar 2020 16:23:20 -0400 [thread overview]
Message-ID: <20200309202322.12327-4-josef@toxicpanda.com> (raw)
In-Reply-To: <20200309202322.12327-1-josef@toxicpanda.com>
In debugging a generic/320 failure on ppc64, Nikolay noticed that
sometimes we'd ENOSPC out with plenty of space to reclaim if we had
committed the transaction. He further discovered that this was because
there was a priority ticket that was small enough to fit in the free
space currently in the space_info. While that is a problem by itself,
it exposed another flaw, that we consider priority tickets in
may_commit_transaction.
Priority tickets are not allowed to commit the transaction, thus we
shouldn't even consider them in may_commit_transaction. Instead we need
to only consider current normal tickets. With this fix in place, we
will properly commit the transaction.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
fs/btrfs/space-info.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
index 8d00a9ee9458..d198cfd45cf7 100644
--- a/fs/btrfs/space-info.c
+++ b/fs/btrfs/space-info.c
@@ -592,10 +592,7 @@ static int may_commit_transaction(struct btrfs_fs_info *fs_info,
else
cur_free_bytes = 0;
- if (!list_empty(&space_info->priority_tickets))
- ticket = list_first_entry(&space_info->priority_tickets,
- struct reserve_ticket, list);
- else if (!list_empty(&space_info->tickets))
+ if (!list_empty(&space_info->tickets))
ticket = list_first_entry(&space_info->tickets,
struct reserve_ticket, list);
bytes_needed = (ticket) ? ticket->bytes : 0;
--
2.24.1
next prev parent reply other threads:[~2020-03-09 20:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-09 20:23 [PATCH 0/5] Deal with a few ENOSPC corner cases Josef Bacik
2020-03-09 20:23 ` [PATCH 1/5] btrfs: Improve global reserve stealing logic Josef Bacik
2020-03-09 20:48 ` Nikolay Borisov
2020-03-10 14:27 ` Nikolay Borisov
2020-03-09 20:23 ` [PATCH 2/5] btrfs: Account for trans_block_rsv in may_commit_transaction Josef Bacik
2020-03-09 20:44 ` Nikolay Borisov
2020-03-09 20:23 ` Josef Bacik [this message]
2020-03-09 20:51 ` [PATCH 3/5] btrfs: only take normal tickets into account " Nikolay Borisov
2020-03-09 23:13 ` Nikolay Borisov
2020-03-10 10:27 ` Nikolay Borisov
2020-03-09 20:23 ` [PATCH 4/5] btrfs: only check priority tickets for priority flushing Josef Bacik
2020-03-10 10:30 ` Nikolay Borisov
2020-03-09 20:23 ` [PATCH 5/5] btrfs: run btrfs_try_granting_tickets if a priority ticket fails Josef Bacik
2020-03-10 10:32 ` Nikolay Borisov
2020-03-13 19:54 ` Josef Bacik
2020-03-10 17:28 ` [PATCH 0/5] Deal with a few ENOSPC corner cases Nikolay Borisov
2020-03-11 1:45 ` David Sterba
2020-03-13 12:37 ` Nikolay Borisov
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=20200309202322.12327-4-josef@toxicpanda.com \
--to=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
/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).