All of lore.kernel.org
 help / color / mirror / Atom feed
From: bingjingc <bingjingc@synology.com>
To: Jes.Sorensen@gmail.com
Cc: linux-raid@vger.kernel.org
Subject: [PATCH] mdadm: prevent out-of-date reshaping devices from force assemble
Date: Tue, 06 Feb 2018 17:09:47 +0800	[thread overview]
Message-ID: <e04a8ec7b4b5f8e8cefac05997c781c1@synology.com> (raw)


With "--force", we can assemble the array even if some superblocks
appear out-of-date. But their data layout is regarded to make sense.
In reshape cases, if two devices claims different reshape progresses,
we cannot forcely assemble them back to array. Kernel will treat only
one of them as reshape progress. However, their data is still laid on
different layouts. It may lead to disaster if reshape goes on.

Reproducible Steps:
mdadm -C /dev/md0 --assume-clean -l5 -n3 /dev/loop[012]
mdadm -a /dev/md0 /dev/loop3
mdadm -G /dev/md0 -n4
mdadm -f /dev/md0 /dev/loop0 # after a period
mdadm -S /dev/md0 # after another period
mdadm -E /dev/loop[01] # make sure that they claims different ones

mdadm -Af -R /dev/md0 /dev/loop[023] # give no enough devices for
force_array() to pick non-fresh devices
cat /sys/block/md0/md/reshape_position # You can see that Kernel resume
reshape the from any progress of them.

Note: The unit of mdadm -E is KB, but reshape_position's is sector.

In order to prevent disaster, we add logics to prevent devices with
different reshape progress from being added into the array.

Reported-by: Allen Peng <allenpeng@synology.com>
Reviewed-by: Alex Wu <alexwu@synology.com>
Signed-off-by: BingJing Chang <bingjingc@synology.com>
---
  Assemble.c | 22 ++++++++++++++++++++--
  1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/Assemble.c b/Assemble.c
index 9e19246..9f33c61 100644
--- a/Assemble.c
+++ b/Assemble.c
@@ -846,7 +846,19 @@ static int force_array(struct mdinfo *content,
  					/* OK */;
  				else
  					continue;
-			}
+			} else if (devices[j].i.reshape_active !=
+			    content->reshape_active ||
+			    (devices[j].i.reshape_active &&
+			    devices[j].i.reshape_progress !=
+			    content->reshape_progress))
+				/* Here, it may be a source of data. If two
+				 * devices claim different progresses, it
+				 * means that reshape boundaries differ for
+				 * their own devices. Kernel will only treat
+				 * the first one as reshape progress and
+				 * go on. It may cause disaster, so avoid it.
+				 */
+				continue;
  			if (chosen_drive < 0 ||
  			     devices[j].i.events
  			    > devices[chosen_drive].i.events)
@@ -908,7 +920,13 @@ static int force_array(struct mdinfo *content,
  			if (j >= 0 &&
  			    !devices[j].uptodate &&
  			    devices[j].i.recovery_start == MaxSector &&
-			    devices[j].i.events == current_events) {
+			    devices[j].i.events == current_events &&
+			    ((!devices[j].i.reshape_active &&
+			    !content->reshape_active) ||
+			    (devices[j].i.reshape_active ==
+			    content->reshape_active &&
+			    devices[j].i.reshape_progress ==
+			    content->reshape_progress))) {
  				chosen_drive = j;
  				goto add_another;
  			}
-- 
2.7.4


                 reply	other threads:[~2018-02-06  9:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=e04a8ec7b4b5f8e8cefac05997c781c1@synology.com \
    --to=bingjingc@synology.com \
    --cc=Jes.Sorensen@gmail.com \
    --cc=linux-raid@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.