From: NeilBrown <neilb@suse.com>
To: Xiao Ni <xni@redhat.com>
Cc: linux-raid@vger.kernel.org
Subject: [PATCH 0/4] RFC: attempt to remove md deadlocks with metadata without
Date: Tue, 12 Sep 2017 11:49:12 +1000 [thread overview]
Message-ID: <150518076229.32691.13542756562323866921.stgit@noble> (raw)
Hi,
I looked again at the previous patch I posted which tried to mak
md_update_sb() safe without taking reconfig_mutex, and realized that
it had serious problems, particularly around devices being added or
removed while the update was happening.
So I decided to try a different approach, which is embodied in these
patches. The md thread is now explicitly allowed to call
md_update_sb() while some other thread holds the lock and
waits for mddev_suspend() to complete.
Please test these and confirm that they still address the problem you
found.
Thanks,
NeilBrown
---
NeilBrown (4):
md: always hold reconfig_mutex when calling mddev_suspend()
md: don't call bitmap_create() while array is quiesced.
md: use mddev_suspend/resume instead of ->quiesce()
md: allow metadata update while suspending.
drivers/md/dm-raid.c | 5 ++++-
drivers/md/md.c | 45 ++++++++++++++++++++++++++++++++-------------
drivers/md/md.h | 6 ++++++
drivers/md/raid5-cache.c | 2 ++
4 files changed, 44 insertions(+), 14 deletions(-)
--
Signature
next reply other threads:[~2017-09-12 1:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-12 1:49 NeilBrown [this message]
2017-09-12 1:49 ` [PATCH 3/4] md: use mddev_suspend/resume instead of ->quiesce() NeilBrown
2017-09-12 1:49 ` [PATCH 1/4] md: always hold reconfig_mutex when calling mddev_suspend() NeilBrown
2017-09-12 1:49 ` [PATCH 4/4] md: allow metadata update while suspending NeilBrown
2017-09-12 1:49 ` [PATCH 2/4] md: don't call bitmap_create() while array is quiesced NeilBrown
2017-09-12 2:51 ` [PATCH 0/4] RFC: attempt to remove md deadlocks with metadata without Xiao Ni
2017-09-13 2:11 ` Xiao Ni
2017-09-13 15:09 ` Xiao Ni
2017-09-13 23:05 ` NeilBrown
2017-09-14 4:55 ` Xiao Ni
2017-09-14 5:32 ` NeilBrown
2017-09-14 7:57 ` Xiao Ni
2017-09-16 13:15 ` Xiao Ni
2017-10-05 5:17 ` NeilBrown
2017-10-06 3:53 ` Xiao Ni
2017-10-06 4:32 ` NeilBrown
2017-10-09 1:21 ` Xiao Ni
2017-10-09 4:57 ` NeilBrown
2017-10-09 5:32 ` Xiao Ni
2017-10-09 5:52 ` NeilBrown
2017-10-10 6:05 ` Xiao Ni
2017-10-10 21:20 ` NeilBrown
[not found] ` <960568852.19225619.1507689864371.JavaMail.zimbra@redhat.com>
2017-10-13 3:48 ` NeilBrown
2017-10-16 4:43 ` Xiao Ni
2017-09-30 9:46 ` Xiao Ni
2017-10-05 5:03 ` NeilBrown
2017-10-06 3:40 ` Xiao Ni
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=150518076229.32691.13542756562323866921.stgit@noble \
--to=neilb@suse.com \
--cc=linux-raid@vger.kernel.org \
--cc=xni@redhat.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.