headers
Mike Viau | 1 Mar 2011 04:19
Picon
Picon

Impact of missing parameter during mdadm create


Hello mdadm hackers,

I was wondering what (if any) impact would creating an array with the missing parameter have on subsequent
assemblies of a mdadm array? 

When the array was created, I used a command like:

mdadm --create -l5 -n3 /dev/md0 /dev/sda1 missing /dev/sdb1

And then loaded some initial data on the md0 array from /dev/sdd1, and then I zeroed out /dev/sdd1 and added
it to the md0 array.

Details on each drive seem to show they all belong to the same Array UUID, but when the array is (re)assembled
(on boot or manually), only /dev/sd{a,b}1 are added to mdadm array automatically, and /dev/sdd1 must be
re-added manually.

> mdadm --examine /dev/sd{a,b,d}1
> /dev/sda1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x0
> Array UUID : 7d8a7c68:95a230d0:0a8f6e74:4c8f81e9
> Name : XEN-HOST:0 (local to host XEN-HOST)
> Creation Time : Mon Dec 20 09:48:07 2010
> Raid Level : raid5
> Raid Devices : 3
> 
> Avail Dev Size : 1953517954 (931.51 GiB 1000.20 GB)
> Array Size : 3907035136 (1863.02 GiB 2000.40 GB)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Mike Viau | 1 Mar 2011 04:59
Picon
Picon

RE: Impact of missing parameter during mdadm create


Manual re-assembly outputs as follows:

mdadm -Ss

mdadm: stopped /dev/md0

---

mdadm -Asvvv

mdadm: looking for devices for /dev/md/0
mdadm: no RAID superblock on /dev/dm-6
mdadm: /dev/dm-6 has wrong uuid.
mdadm: no RAID superblock on /dev/dm-5
mdadm: /dev/dm-5 has wrong uuid.
mdadm: no RAID superblock on /dev/dm-4
mdadm: /dev/dm-4 has wrong uuid.
mdadm: no RAID superblock on /dev/dm-3
mdadm: /dev/dm-3 has wrong uuid.
mdadm: cannot open device /dev/dm-2: Device or resource busy
mdadm: /dev/dm-2 has wrong uuid.
mdadm: no RAID superblock on /dev/dm-1
mdadm: /dev/dm-1 has wrong uuid.
mdadm: no RAID superblock on /dev/dm-0
mdadm: /dev/dm-0 has wrong uuid.
mdadm: no RAID superblock on /dev/sde
mdadm: /dev/sde has wrong uuid.
mdadm: no RAID superblock on /dev/sdd
mdadm: /dev/sdd has wrong uuid.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Kwolek | 1 Mar 2011 15:56
Picon
Favicon

[PATCH 0/7] Grow_continue, use in assembly (cont.)

The following series implements next part of resuming reshape from checkpoint.
In this series call to invoke reshape is included.
It is required to have backup file to run reshape, so backup file validation is added
(without checking in file system)
Array seams to be configured for reshape, monitor is blocked and doesn't makes changes
to process. On the end of reshape monitor unblock is placed also.

In patch:
   Continue reshape after assembling array
some plans for supporting container operations is placed.

Reshape restoring is not working yet (a few more pathes are still required)
I hope some of therm I'll post tomorrow.

BR
Adam

---

Adam Kwolek (7):
      FIX: array is frozen after reshape
      Continue reshape after assembling array
      FIX: Block monitor when starting array with reshape in progress
      Add block_subarray()
      FIX: configure disks slot for expansion
      FIX: reshape in md should wait for monitoring process (external metadata)
      FIX: Verify Backup file name before reshape

 Assemble.c    |   64 +++++++++++++++++++++++++++++++++++++++++++++------------
 Grow.c        |   15 ++++++++++++-
(Continue reading)

Permalink | Reply | 14 comments |
headers
Adam Kwolek | 1 Mar 2011 15:56
Picon
Favicon

[PATCH 1/7] FIX: Verify Backup file name before reshape

When reshape is continued backup_file is required for user data safety.
Grow_continue() has to verify if any file name is passed in.

Signed-off-by: Adam Kwolek <adam.kwolek <at> intel.com>
---

 Grow.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/Grow.c b/Grow.c
index 47b8809..1470a91 100644
--- a/Grow.c
+++ b/Grow.c
 <at>  <at>  -3332,6 +3332,11  <at>  <at>  int Grow_continue(int mdfd, struct supertype *st, struct mdinfo *info,
 	char *container = NULL;
 	int err;

+	if (backup_file == NULL) {
+		fprintf(stderr, Name ": Backup file name has to be specified "
+			"for reshape continuation.\n");
+		return 1;
+	}
 	if (!st->ss->external) {
 		err = sysfs_set_str(info, NULL, "array_state", "readonly");
 		if (err)

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adam Kwolek | 1 Mar 2011 15:57
Picon
Favicon

[PATCH 3/7] FIX: configure disks slot for expansion

Some raid_disks that are used for expansion, are not configured yet.
This is due to earlier set raid_disks limitation.
Set raid_disks to new (bigger) value and finish disks slot configuration.

Signed-off-by: Adam Kwolek <adam.kwolek <at> intel.com>
---

 Assemble.c |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/Assemble.c b/Assemble.c
index 6aff049..fa3a0a6 100644
--- a/Assemble.c
+++ b/Assemble.c
 <at>  <at>  -1586,9 +1586,22  <at>  <at>  int assemble_container_content(struct supertype *st, int mdfd,
 					chosen_name, working + preexist);
 			if (preexist)
 				fprintf(stderr, " (%d new)", working);
-			if (expansion)
+			if (expansion) {
 				fprintf(stderr, " ( + %d for expansion)",
 					expansion);
+			sysfs_set_num(content, NULL, "raid_disks",
+				      content->array.raid_disks + expansion);
+			for (dev = content->devs; dev; dev = dev->next)
+				if (dev->disk.raid_disk >=
+				    content->array.raid_disks) {
+					int rv;
+					dprintf("\n\tExpansion: configure slot:"
+						"%i", dev->disk.raid_disk);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adam Kwolek | 1 Mar 2011 15:56
Picon
Favicon

[PATCH 2/7] FIX: reshape in md should wait for monitoring process (external metadata)

When container content is assembled it is possible that reshape
is in progress. To avoid md to run reshape without monitoring.
Before setting array parameters sync_max is set to 0, to not allow md
for any move forward. After array parameters are set, sync_max is set to current
reshape_progress. This is current reshape start point.
Note that md is still blocked, and reshape is not continued.

Signed-off-by: Adam Kwolek <adam.kwolek <at> intel.com>
---

 Assemble.c |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/Assemble.c b/Assemble.c
index 4d41081..6aff049 100644
--- a/Assemble.c
+++ b/Assemble.c
 <at>  <at>  -1510,11 +1510,26  <at>  <at>  int assemble_container_content(struct supertype *st, int mdfd,
 	sysfs_init(content, mdfd, 0);

 	sra = sysfs_read(mdfd, 0, GET_VERSION);
-	if (sra == NULL || strcmp(sra->text_version, content->text_version) != 0)
+	if (sra == NULL || strcmp(sra->text_version,
+				  content->text_version) != 0) {
+		if (content->reshape_active) {
+			/* block reshape until reshape monitoring
+			 * allows for run
+			 */
+			sysfs_set_num(content, NULL, "sync_max", 0);
+		}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam Kwolek | 1 Mar 2011 15:57
Picon
Favicon

[PATCH 4/7] Add block_subarray()

Put code for blocking subarray in to separate function.
This little code/function will be used for blocking arrays from mdmon
monitoring during assembly process. Arrays cannot wait for container
assembly finish, because meanwhile monitor can enable arrays for writing.

Signed-off-by: Adam Kwolek <adam.kwolek <at> intel.com>
---

 msg.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/msg.c b/msg.c
index 76e74e7..ce2ce00 100644
--- a/msg.c
+++ b/msg.c
 <at>  <at>  -255,6 +255,18  <at>  <at>  static int unblock_subarray(struct mdinfo *sra, const int unfreeze)
 	return rc;
 }

+int block_subarray(struct mdinfo *sra)
+{
+	char buf[64];
+	int rc = 0;
+
+	sprintf(buf, "external:%s\n", sra->text_version);
+	buf[9] = '-';
+	if (sysfs_set_str(sra, NULL, "metadata_version", buf))
+		rc = -1;
+
+	return rc;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Kwolek | 1 Mar 2011 15:57
Picon
Favicon

[PATCH 6/7] Continue reshape after assembling array

assemble_container_content() cannot close mdfd handle, as it could be
required by reshape continuation.
mdfd handle is closed outside this function, when it is not longer necessary.
Call to Grow_continue is added for reshape continuation after assembly.

In the nearest future, simple condition:
    if (content->reshape_active)
before Grow_continue() call will be replaced by check function
for support container operation /reshape/.
Additional call to the same check function will be added inside Grow_continue()
after fork command, to find out if reshape pointed by metadata applies to current array
or we should wait for it (another array is under reshape).

Signed-off-by: Adam Kwolek <adam.kwolek <at> intel.com>

Conflicts:

	Assemble.c
---

 Assemble.c    |   32 ++++++++++++++++++++------------
 Incremental.c |    1 +
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/Assemble.c b/Assemble.c
index 9d17a57..c3d8914 100644
--- a/Assemble.c
+++ b/Assemble.c
 <at>  <at>  -696,8 +696,21  <at>  <at>  int Assemble(struct supertype *st, char *mddev,
 #ifndef MDASSEMBLE
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Kwolek | 1 Mar 2011 15:57
Picon
Favicon

[PATCH 5/7] FIX: Block monitor when starting array with reshape in progress

To allow for array reconfiguration, mdmon cannot push array in to active
state. Assemble should block monitor for external metadata to allow
for reshape configuration and restart.

Signed-off-by: Adam Kwolek <adam.kwolek <at> intel.com>
---

 Assemble.c |    2 ++
 msg.h      |    1 +
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/Assemble.c b/Assemble.c
index fa3a0a6..9d17a57 100644
--- a/Assemble.c
+++ b/Assemble.c
 <at>  <at>  -1528,8 +1528,10  <at>  <at>  int assemble_container_content(struct supertype *st, int mdfd,
 			 */
 			sysfs_set_num(content, NULL, "sync_max",
 				      content->reshape_progress);
+			block_subarray(content);
 		}
 	}
+
 	if (sra)
 		sysfs_free(sra);

diff --git a/msg.h b/msg.h
index 1f916de..090d3f6 100644
--- a/msg.h
+++ b/msg.h
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Kwolek | 1 Mar 2011 15:57
Picon
Favicon

[PATCH 7/7] FIX: array is frozen after reshape

When we fork() process, we do not need another fork inside reshape_array().
We can indicate it by fork flag.
In such case Grow_continue() is responsible for unfreezing array
after return from reshape_array() function.

Signed-off-by: Adam Kwolek <adam.kwolek <at> intel.com>
---

 Grow.c |   10 ++++++++--
 msg.c  |    2 +-
 msg.h  |    1 +
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/Grow.c b/Grow.c
index 1470a91..fc90aa5 100644
--- a/Grow.c
+++ b/Grow.c
 <at>  <at>  -3331,6 +3331,7  <at>  <at>  int Grow_continue(int mdfd, struct supertype *st, struct mdinfo *info,
 	char buf[40];
 	char *container = NULL;
 	int err;
+	int forked = 0;

 	if (backup_file == NULL) {
 		fprintf(stderr, Name ": Backup file name has to be specified "
 <at>  <at>  -3354,11 +3355,16  <at>  <at>  int Grow_continue(int mdfd, struct supertype *st, struct mdinfo *info,
 		case 0:
 			dprintf(Name ": Continue bacground reshape "
 				"after assemblation\n");
+			forked = 1;
(Continue reading)

Permalink | Reply | 0 comments |

Gmane