Add '--nodes' option in GROW mode

PATCH Applied zhilong 3 participants 6 messages Mar 22, 2016 – Mar 29, 2016 MD RAID

lore

Share & tools

lore

zhilong

author

2016-03-22 11:44 UTC #0 lore raw

PATCH 1/1 Add '--nodes' option in GROW mode

Bug description:

# mdadm -Cv /dev/md0 --bitmap=clustered -l1 -n2 /dev/sdd /dev/sdb --nodes=6 --assume-clean
# mdadm --grow /dev/md0 --bitmap=none
# mdadm --grow /dev/md0 --bitmap=clustered
    -> cluster nodes would be changed to 4, here is my method to 
resolve it.
# mdadm --grow /dev/md0 --bitmap=clustered --nodes=6

Patch:

Cluster nodes is set 4 as default when switch bitmap from none to clustered under GROW mode, so add '--nodes' option in GROW mode.

Signed-off-by Zhilong Liu <[email protected]>

---
 mdadm.c | 1 +
 1 file changed, 1 insertion(+)

mdadm.c +1 -0

index 51e16f3..b542b8c 100644
@@ -592,6 +592,7 @@ int main(int argc, char *argv[])
             ident.raid_disks = s.raiddisks;
             continue;
         case O(ASSEMBLE, Nodes):
+        case O(GROW, Nodes):
         case O(CREATE, Nodes):
             c.nodes = parse_num(optarg);
             if (c.nodes <= 0) {

Signature · 1 line

2.1.4

Jes Sorensen

2016-03-22 17:56 UTC #1 lore raw

Quoted 11 lines · zhilong

Bug description:

# mdadm -Cv /dev/md0 --bitmap=clustered -l1 -n2 /dev/sdd /dev/sdb
--nodes=6 --assume-clean
# mdadm --grow /dev/md0 --bitmap=none
# mdadm --grow /dev/md0 --bitmap=clustered
    -> cluster nodes would be changed to 4, here is my method to
resolve it.
# mdadm --grow /dev/md0 --bitmap=clustered --nodes=6

Patch:

Quoted 8 lines

Cluster nodes is set 4 as default when switch bitmap from none to clustered under GROW mode, so add '--nodes' option in GROW mode.
Signed-off-by Zhilong Liu <[email protected]>
---
 mdadm.c | 1 +
 1 file changed, 1 insertion(+)

Hi,

I have a question about this, since I simply do not have the knowledge about clustering to judge this approach.

If you remove the bitmap, does that 'uncluster' the array? If not, shouldn't mdadm be fixed to not set #nodes to 4 when adding a clustered bitmap, if a number of cluster nodes is already present?

Thanks,
Jes

Quoted 13 lines

mdadm.c +1 -0

index 51e16f3..b542b8c 100644
@@ -592,6 +592,7 @@ int main(int argc, char *argv[])
             ident.raid_disks = s.raiddisks;
             continue;
         case O(ASSEMBLE, Nodes):
+        case O(GROW, Nodes):
         case O(CREATE, Nodes):
             c.nodes = parse_num(optarg);
             if (c.nodes <= 0) {

Guoqing Jiang

2016-03-23 11:38 UTC #2 lore raw

Quoted 20 lines · Jes Sorensen

Quoted 11 lines · zhilong
Bug description:
# mdadm -Cv /dev/md0 --bitmap=clustered -l1 -n2 /dev/sdd /dev/sdb
--nodes=6 --assume-clean
# mdadm --grow /dev/md0 --bitmap=none
# mdadm --grow /dev/md0 --bitmap=clustered
     -> cluster nodes would be changed to 4, here is my method to
resolve it.
# mdadm --grow /dev/md0 --bitmap=clustered --nodes=6
Patch:
Quoted 8 lines
Cluster nodes is set 4 as default when switch bitmap from none to clustered under GROW mode, so add '--nodes' option in GROW mode.
Signed-off-by Zhilong Liu <[email protected]>
---
  mdadm.c | 1 +
  1 file changed, 1 insertion(+)

Quoted 6 lines

Hi,
I have a question about this, since I simply do not have the knowledge about clustering to judge this approach.
If you remove the bitmap, does that 'uncluster' the array? If not,

Yes, remove the bitmap would 'uncluster' the array since leave() will be called in kernel if switch the bitmap from 'clustered' to 'none'.

Quoted 2 lines

shouldn't mdadm be fixed to not set #nodes to 4 when adding a clustered bitmap, if a number of cluster nodes is already present?

The nodes is set 4 by default if the 'nodes' parameter is not specified, And it could be overwrite if re-create the clustered bitmap.

Thanks,
Guoqing

Jes Sorensen

2016-03-24 16:31 UTC #3 lore raw

Quoted 32 lines · Guoqing Jiang

Quoted 20 lines · Jes Sorensen
Quoted 11 lines · zhilong
Bug description:
# mdadm -Cv /dev/md0 --bitmap=clustered -l1 -n2 /dev/sdd /dev/sdb
--nodes=6 --assume-clean
# mdadm --grow /dev/md0 --bitmap=none
# mdadm --grow /dev/md0 --bitmap=clustered
     -> cluster nodes would be changed to 4, here is my method to
resolve it.
# mdadm --grow /dev/md0 --bitmap=clustered --nodes=6
Patch:
Quoted 8 lines
Cluster nodes is set 4 as default when switch bitmap from none to clustered under GROW mode, so add '--nodes' option in GROW mode.
Signed-off-by Zhilong Liu <[email protected]>
---
  mdadm.c | 1 +
  1 file changed, 1 insertion(+)
Quoted 6 lines
Hi,
I have a question about this, since I simply do not have the knowledge about clustering to judge this approach.
If you remove the bitmap, does that 'uncluster' the array? If not,
Yes, remove the bitmap would 'uncluster' the array since leave() will be called in kernel if switch the bitmap from 'clustered' to 'none'.

Quoted 5 lines

Quoted 2 lines
shouldn't mdadm be fixed to not set #nodes to 4 when adding a clustered bitmap, if a number of cluster nodes is already present?
The nodes is set 4 by default if the 'nodes' parameter is not specified, And it could be overwrite if re-create the clustered bitmap.

Thanks for the explanation, in that case I am fine with this. It does raise the issue whether specifying nodes shouldn't be a required argument rather than defaulting to a default of 4?

Second, your patch was broken due to bad whitespace formatting, could you please send me a fresh one.

Thanks,
Jes

zhilong

author

2016-03-25 02:22 UTC #4 lore raw

Re: [PATCH] mdadm:Add '--nodes' option in GROW mode

mdadm:add '--nodes' option in GROW mode, because 'Cluster nodes' is set 4 by default if the nodes parameter is not specified when switch bitmap from none to clustered.

Signed-off-by Zhilong Liu <[email protected]>

---
 mdadm.c | 1 +
 1 file changed, 1 insertion(+)

mdadm.c +1 -0

index d2afcb2..58ac32a 100644
@@ -589,6 +589,7 @@ int main(int argc, char *argv[])
 			ident.raid_disks = s.raiddisks;
 			continue;
 		case O(ASSEMBLE, Nodes):
+		case O(GROW, Nodes):
 		case O(CREATE, Nodes):
 			c.nodes = parse_num(optarg);
 			if (c.nodes <= 0) {

Signature · 1 line

2.1.4

Quoted 50 lines · Jes Sorensen

Quoted 27 lines · Guoqing Jiang
Quoted 20 lines · Jes Sorensen
Quoted 11 lines · zhilong
Bug description:
# mdadm -Cv /dev/md0 --bitmap=clustered -l1 -n2 /dev/sdd /dev/sdb
--nodes=6 --assume-clean
# mdadm --grow /dev/md0 --bitmap=none
# mdadm --grow /dev/md0 --bitmap=clustered
      -> cluster nodes would be changed to 4, here is my method to
resolve it.
# mdadm --grow /dev/md0 --bitmap=clustered --nodes=6
Patch:
Quoted 8 lines
Cluster nodes is set 4 as default when switch bitmap from none to clustered under GROW mode, so add '--nodes' option in GROW mode.
Signed-off-by Zhilong Liu <[email protected]>
---
   mdadm.c | 1 +
   1 file changed, 1 insertion(+)
Quoted 6 lines
Hi,
I have a question about this, since I simply do not have the knowledge about clustering to judge this approach.
If you remove the bitmap, does that 'uncluster' the array? If not,
Quoted 8 lines
Yes, remove the bitmap would 'uncluster' the array since leave() will be called in kernel if switch the bitmap from 'clustered' to 'none'.
Quoted 2 lines
shouldn't mdadm be fixed to not set #nodes to 4 when adding a clustered bitmap, if a number of cluster nodes is already present?
The nodes is set 4 by default if the 'nodes' parameter is not specified, And it could be overwrite if re-create the clustered bitmap.
Thanks for the explanation, in that case I am fine with this. It does raise the issue whether specifying nodes shouldn't be a required argument rather than defaulting to a default of 4?
Second, your patch was broken due to bad whitespace formatting, could you please send me a fresh one.
Thanks,
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Something funny happened to the formatting of your patch. Somehow it ended up with an additional space at the beginning of each line. Not sure if it is related to your mail client using format-flowed.

I manually fixed it up, so it's all good.

Thanks,
Jes