Hi,
在 2024/08/30 19:06, Mariusz Tkaczyk 写道:
On Fri, 30 Aug 2024 15:27:18 +0800
Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote:
From: Yu Kuai <yukuai3@xxxxxxxxxx>
Currently raid1 is preparing IO for underlying disks while checking if
any disk is blocked, if so allocated resources must be released, then
waiting for rdev to be unblocked and try to prepare IO again.
Make code cleaner by checking blocked rdev first, it doesn't matter if
rdev is blocked while issuing this IO.
Signed-off-by: Yu Kuai <yukuai3@xxxxxxxxxx>
---
drivers/md/raid1.c | 84 ++++++++++++++++++++++++++--------------------
1 file changed, 48 insertions(+), 36 deletions(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index f55c8e67d059..aa30c3240c85 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1406,6 +1406,49 @@ static void raid1_read_request(struct mddev *mddev,
struct bio *bio, submit_bio_noacct(read_bio);
}
+static bool wait_blocked_rdev(struct mddev *mddev, struct bio *bio)
+{
+ struct r1conf *conf = mddev->private;
+ int disks = conf->raid_disks * 2;
+ int i;
+
+retry:
+ for (i = 0; i < disks; i++) {
+ struct md_rdev *rdev = conf->mirrors[i].rdev;
+
+ if (!rdev)
+ continue;
+
+ if (test_bit(Blocked, &rdev->flags)) {
Don't we need unlikely here?
+ if (bio->bi_opf & REQ_NOWAIT)
+ return false;
+
+ mddev_add_trace_msg(rdev->mddev, "raid1 wait rdev %d
blocked",
+ rdev->raid_disk);
+ atomic_inc(&rdev->nr_pending);
retry moves us before for (ugh, ugly) and "theoretically" we can back here
with the same disk and increase nr_pending twice or more because rdve can become
block again from different thread.
Rety is always after md_wait_for_blocked_rdev(), which decrease the
nr_pending.
Thanks,
Kuai
This is what I suspect but it could be wrong.
Mariusz
.
