public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Cc: naohiro.aota@wdc.com, Filipe Manana <fdmanana@suse.com>
Subject: [PATCH 0/2] btrfs: eliminate a deadlock when allocating system chunks and rework chunk allocation
Date: Tue, 29 Jun 2021 14:43:04 +0100	[thread overview]
Message-ID: <cover.1624973480.git.fdmanana@suse.com> (raw)

From: Filipe Manana <fdmanana@suse.com>

The first patch eliminates a deadlock when multiple tasks need to allocate
a system chunk. It reverts a previous fix for a problem that resulted in
exhausting the system chunk array and result in a transaction abort when
there are many tasks allocating chunks in parallel. Since there is not a
simple and short fix for the deadlock that does not bring back the system
array exhaustion problem, and the deadlock is relatively easy to trigger
on zoned filesystem while the exhaustion problem is not so common, this
first patch just revets that previous fix.

The second patch reworks a bit of the chunk allocation code so that we
don't hold onto reserved system space from phase 1 to phase 2 of chunk
allocation, which is what leads to system chunk array exhaustion when
there's a bunch of tasks doing chunks allocations in parallel (initially
observed on PowerPC, with a 64K node size, when running the fallocate
tests from stress-ng). The diff of this patch is quite big, but about
half of it are just comments.

Filipe Manana (2):
  btrfs: fix deadlock with concurrent chunk allocations involving system
    chunks
  btrfs: rework chunk allocation to avoid exhaustion of the system chunk
    array

 fs/btrfs/block-group.c | 343 ++++++++++++++++++++++++++++-----------
 fs/btrfs/block-group.h |   6 +-
 fs/btrfs/ctree.c       |  67 ++------
 fs/btrfs/transaction.c |  15 +-
 fs/btrfs/transaction.h |   9 +-
 fs/btrfs/volumes.c     | 355 +++++++++++++++++++++++++++++++----------
 fs/btrfs/volumes.h     |   5 +-
 7 files changed, 547 insertions(+), 253 deletions(-)

-- 
2.28.0


             reply	other threads:[~2021-06-29 13:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 13:43 fdmanana [this message]
2021-06-29 13:43 ` [PATCH 1/2] btrfs: fix deadlock with concurrent chunk allocations involving system chunks fdmanana
2021-06-29 13:43 ` [PATCH 2/2] btrfs: rework chunk allocation to avoid exhaustion of the system chunk array fdmanana
2021-07-02  8:52   ` Nikolay Borisov
2021-07-02  9:22     ` Filipe Manana
2021-06-30 13:10 ` [PATCH 0/2] btrfs: eliminate a deadlock when allocating system chunks and rework chunk allocation David Sterba
2021-06-30 14:50   ` Johannes Thumshirn
2021-06-30 18:33     ` David Sterba
2021-07-01  3:59 ` Shinichiro Kawasaki
2021-07-01  7:15 ` Naohiro Aota

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=cover.1624973480.git.fdmanana@suse.com \
    --to=fdmanana@kernel.org \
    --cc=fdmanana@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=naohiro.aota@wdc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox