From: Josef Bacik <jbacik@fusionio.com>
To: Liu Bo <bo.li.liu@oracle.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Jim Schutt <jaschut@sandia.gov>
Subject: Re: [PATCH] Btrfs: fix a deadlock on chunk mutex
Date: Tue, 18 Dec 2012 08:52:42 -0500 [thread overview]
Message-ID: <20121218135242.GC2403@localhost.localdomain> (raw)
In-Reply-To: <1355363557-2962-1-git-send-email-bo.li.liu@oracle.com>
On Wed, Dec 12, 2012 at 06:52:37PM -0700, Liu Bo wrote:
> An user reported that he has hit an annoying deadlock while playing with
> ceph based on btrfs.
>
> Current updating device tree requires space from METADATA chunk,
> so we -may- need to do a recursive chunk allocation when adding/updating
> dev extent, that is where the deadlock comes from.
>
> If we use SYSTEM metadata to update device tree, we can avoid the recursive
> stuff.
>
This is going to cause us to allocate much more system chunks than we used to
which could land us in trouble. Instead let's just keep us from re-entering if
we're already allocating a chunk. We do the chunk allocation when we don't have
enough space for a cluster, but we'll likely have plenty of space to make an
allocation. Can you give this patch a try Jim and see if it fixes your problem?
Thanks,
Josef
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index e152809..59df5e7 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3564,6 +3564,10 @@ static int do_chunk_alloc(struct btrfs_trans_handle *trans,
int wait_for_alloc = 0;
int ret = 0;
+ /* Don't re-enter if we're already allocating a chunk */
+ if (trans->allocating_chunk)
+ return -ENOSPC;
+
space_info = __find_space_info(extent_root->fs_info, flags);
if (!space_info) {
ret = update_space_info(extent_root->fs_info, flags,
@@ -3606,6 +3610,8 @@ again:
goto again;
}
+ trans->allocating_chunk = true;
+
/*
* If we have mixed data/metadata chunks we want to make sure we keep
* allocating mixed chunks instead of individual chunks.
@@ -3632,6 +3638,7 @@ again:
check_system_chunk(trans, extent_root, flags);
ret = btrfs_alloc_chunk(trans, extent_root, flags);
+ trans->allocating_chunk = false;
if (ret < 0 && ret != -ENOSPC)
goto out;
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index e6509b9..47ad8be 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -388,6 +388,7 @@ again:
h->qgroup_reserved = qgroup_reserved;
h->delayed_ref_elem.seq = 0;
h->type = type;
+ h->allocating_chunk = false;
INIT_LIST_HEAD(&h->qgroup_ref_list);
INIT_LIST_HEAD(&h->new_bgs);
diff --git a/fs/btrfs/transaction.h b/fs/btrfs/transaction.h
index 0e8aa1e..69700f7 100644
--- a/fs/btrfs/transaction.h
+++ b/fs/btrfs/transaction.h
@@ -68,6 +68,7 @@ struct btrfs_trans_handle {
struct btrfs_block_rsv *orig_rsv;
short aborted;
short adding_csums;
+ bool allocating_chunk;
enum btrfs_trans_type type;
/*
* this root is only needed to validate that the root passed to
next prev parent reply other threads:[~2012-12-18 13:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-13 1:52 [PATCH] Btrfs: fix a deadlock on chunk mutex Liu Bo
2012-12-18 13:52 ` Josef Bacik [this message]
2012-12-18 14:47 ` Liu Bo
2012-12-18 15:40 ` Josef Bacik
2013-01-03 18:44 ` Jim Schutt
2013-01-28 21:23 ` Josef Bacik
2013-01-28 21:58 ` Jim Schutt
2013-01-29 2:30 ` Liu Bo
2013-01-29 13:47 ` Josef Bacik
2013-01-29 13:50 ` Josef Bacik
2013-01-29 16:43 ` David Sterba
2013-01-29 16:52 ` David Sterba
2013-01-29 18:41 ` Jim Schutt
2013-01-29 20:04 ` Josef Bacik
2013-01-29 20:37 ` Jim Schutt
2013-01-29 23:05 ` Jim Schutt
2013-01-30 15:06 ` Josef Bacik
2013-01-30 15:16 ` Josef Bacik
2013-01-30 16:38 ` Josef Bacik
2013-01-30 21:37 ` Jim Schutt
2013-01-30 21:55 ` Josef Bacik
2013-01-31 15:33 ` Josef Bacik
2013-01-31 16:52 ` Jim Schutt
2014-02-18 15:47 ` Alex Lyakas
2014-02-18 16:06 ` Josef Bacik
2014-02-18 16:24 ` Alex Lyakas
2014-02-18 16:26 ` Josef Bacik
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=20121218135242.GC2403@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=bo.li.liu@oracle.com \
--cc=jaschut@sandia.gov \
--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).