[3.13.y.z extended stable] Patch "md/raid1: make sure resync waits for conflicting writes to complete." has been added to staging queue

Kamal Mostafa kamal at canonical.com
Thu Oct 9 20:51:44 UTC 2014


This is a note to let you know that I have just added a patch titled

    md/raid1: make sure resync waits for conflicting writes to complete.

to the linux-3.13.y-queue branch of the 3.13.y.z extended stable tree 
which can be found at:

 http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.13.y-queue

This patch is scheduled to be released in version 3.13.11.9.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.13.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Kamal

------

>From 4d191a02b7c35a92fc20d37e7ccd51fd044ea271 Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb at suse.de>
Date: Wed, 10 Sep 2014 15:01:49 +1000
Subject: md/raid1: make sure resync waits for conflicting writes to complete.

commit 2f73d3c55d09ce60647b96ad2a9b539c95a530ee upstream.

The resync/recovery process for raid1 was recently changed
so that writes could happen in parallel with resync providing
they were in different regions of the device.

There is a problem though:  While a write request will always
wait for conflicting resync to complete, a resync request
will *not* always wait for conflicting writes to complete.

Two changes are needed to fix this:

1/ raise_barrier (which waits until it is safe to do resync)
   must wait until current_window_requests is zero
2/ wait_battier (which waits at the start of a new write request)
   must update current_window_requests if the request could
   possible conflict with a concurrent resync.

As concurrent writes and resync can lead to data loss,
this patch is suitable for -stable.

Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Cc: majianpeng <majianpeng at gmail.com>
Signed-off-by: NeilBrown <neilb at suse.de>
[ kamal: backport to 3.13-stable: no bi_iter struct ]
Signed-off-by: Kamal Mostafa <kamal at canonical.com>
---
 drivers/md/raid1.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 2414a79..c85ac43 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -847,10 +847,12 @@ static void raise_barrier(struct r1conf *conf)
 	 * C: next_resync + RESYNC_SECTORS > start_next_window, meaning
 	 *    next resync will reach to the window which normal bios are
 	 *    handling.
+	 * D: while there are any active requests in the current window.
 	 */
 	wait_event_lock_irq(conf->wait_barrier,
 			    !conf->array_frozen &&
 			    conf->barrier < RESYNC_DEPTH &&
+			    conf->current_window_requests == 0 &&
 			    (conf->start_next_window >=
 			     conf->next_resync + RESYNC_SECTORS),
 			    conf->resync_lock);
@@ -917,8 +919,8 @@ static sector_t wait_barrier(struct r1conf *conf, struct bio *bio)
 	}

 	if (bio && bio_data_dir(bio) == WRITE) {
-		if (conf->next_resync + NEXT_NORMALIO_DISTANCE
-		    <= bio->bi_sector) {
+		if (bio->bi_sector >=
+		    conf->next_resync) {
 			if (conf->start_next_window == MaxSector)
 				conf->start_next_window =
 					conf->next_resync +
--
1.9.1





More information about the kernel-team mailing list