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 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.