* [PATCH 1/7] FIX: Verify Backup file name before reshape
2011-03-01 14:56 [PATCH 0/7] Grow_continue, use in assembly (cont.) Adam Kwolek
@ 2011-03-01 14:56 ` Adam Kwolek
2011-03-02 1:01 ` NeilBrown
2011-03-01 14:56 ` [PATCH 2/7] FIX: reshape in md should wait for monitoring process (external metadata) Adam Kwolek
` (6 subsequent siblings)
7 siblings, 1 reply; 15+ messages in thread
From: Adam Kwolek @ 2011-03-01 14:56 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
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@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
@@ -3332,6 +3332,11 @@ 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)
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH 1/7] FIX: Verify Backup file name before reshape
2011-03-01 14:56 ` [PATCH 1/7] FIX: Verify Backup file name before reshape Adam Kwolek
@ 2011-03-02 1:01 ` NeilBrown
2011-03-02 7:39 ` Kwolek, Adam
0 siblings, 1 reply; 15+ messages in thread
From: NeilBrown @ 2011-03-02 1:01 UTC (permalink / raw)
To: Adam Kwolek
Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
On Tue, 01 Mar 2011 15:56:50 +0100 Adam Kwolek <adam.kwolek@intel.com> wrote:
> 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@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
> @@ -3332,6 +3332,11 @@ 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)
reshape_array already performs checks to ensure that backup_file is set when
needed - it isn't always needed.
Is there some reason those checks are not enough?
NeilBrown
^ permalink raw reply [flat|nested] 15+ messages in thread* RE: [PATCH 1/7] FIX: Verify Backup file name before reshape
2011-03-02 1:01 ` NeilBrown
@ 2011-03-02 7:39 ` Kwolek, Adam
0 siblings, 0 replies; 15+ messages in thread
From: Kwolek, Adam @ 2011-03-02 7:39 UTC (permalink / raw)
To: NeilBrown
Cc: linux-raid@vger.kernel.org, Williams, Dan J, Ciechanowski, Ed,
Neubauer, Wojciech
> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Wednesday, March 02, 2011 2:02 AM
> To: Kwolek, Adam
> Cc: linux-raid@vger.kernel.org; Williams, Dan J; Ciechanowski, Ed;
> Neubauer, Wojciech
> Subject: Re: [PATCH 1/7] FIX: Verify Backup file name before reshape
>
> On Tue, 01 Mar 2011 15:56:50 +0100 Adam Kwolek <adam.kwolek@intel.com>
> wrote:
>
> > 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@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
> > @@ -3332,6 +3332,11 @@ 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)
>
>
> reshape_array already performs checks to ensure that backup_file is set
> when
> needed - it isn't always needed.
>
> Is there some reason those checks are not enough?
If container operation will be introduced,
check in reshape_array() will be in forked part of code and Assembly will not know results.
BR
Adam
>
> NeilBrown
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/7] FIX: reshape in md should wait for monitoring process (external metadata)
2011-03-01 14:56 [PATCH 0/7] Grow_continue, use in assembly (cont.) Adam Kwolek
2011-03-01 14:56 ` [PATCH 1/7] FIX: Verify Backup file name before reshape Adam Kwolek
@ 2011-03-01 14:56 ` Adam Kwolek
2011-03-02 1:06 ` NeilBrown
2011-03-01 14:57 ` [PATCH 3/7] FIX: configure disks slot for expansion Adam Kwolek
` (5 subsequent siblings)
7 siblings, 1 reply; 15+ messages in thread
From: Adam Kwolek @ 2011-03-01 14:56 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
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@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
@@ -1510,11 +1510,26 @@ 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);
+ }
if (sysfs_set_array(content, md_get_version(mdfd)) != 0) {
close(mdfd);
return 1;
}
+ if (content->reshape_active) {
+ /* set the current checkpoint to allow monitoring to
+ * restart reshape
+ */
+ sysfs_set_num(content, NULL, "sync_max",
+ content->reshape_progress);
+ }
+ }
if (sra)
sysfs_free(sra);
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH 2/7] FIX: reshape in md should wait for monitoring process (external metadata)
2011-03-01 14:56 ` [PATCH 2/7] FIX: reshape in md should wait for monitoring process (external metadata) Adam Kwolek
@ 2011-03-02 1:06 ` NeilBrown
0 siblings, 0 replies; 15+ messages in thread
From: NeilBrown @ 2011-03-02 1:06 UTC (permalink / raw)
To: Adam Kwolek
Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
On Tue, 01 Mar 2011 15:56:58 +0100 Adam Kwolek <adam.kwolek@intel.com> wrote:
> 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@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
> @@ -1510,11 +1510,26 @@ 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);
> + }
> if (sysfs_set_array(content, md_get_version(mdfd)) != 0) {
> close(mdfd);
> return 1;
> }
> + if (content->reshape_active) {
> + /* set the current checkpoint to allow monitoring to
> + * restart reshape
> + */
> + sysfs_set_num(content, NULL, "sync_max",
> + content->reshape_progress);
> + }
> + }
> if (sra)
> sysfs_free(sra);
>
I fairly sure this is completely ineffective.
At this point the array has not been started, so 'sync_max' does not exist.
It doesn't appear until the array is activated.
We avoid restart starting early by assembling the array 'readonly' as reshape
cannot progress on a read-only array.
NeilBrown
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 3/7] FIX: configure disks slot for expansion
2011-03-01 14:56 [PATCH 0/7] Grow_continue, use in assembly (cont.) Adam Kwolek
2011-03-01 14:56 ` [PATCH 1/7] FIX: Verify Backup file name before reshape Adam Kwolek
2011-03-01 14:56 ` [PATCH 2/7] FIX: reshape in md should wait for monitoring process (external metadata) Adam Kwolek
@ 2011-03-01 14:57 ` Adam Kwolek
2011-03-02 1:10 ` NeilBrown
2011-03-01 14:57 ` [PATCH 4/7] Add block_subarray() Adam Kwolek
` (4 subsequent siblings)
7 siblings, 1 reply; 15+ messages in thread
From: Adam Kwolek @ 2011-03-01 14:57 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
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@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
@@ -1586,9 +1586,22 @@ 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);
+ rv = sysfs_set_num(content, dev, "slot",
+ dev->disk.raid_disk);
+ dprintf(" (status = %i)\n", rv);
+ }
+ }
fprintf(stderr, "\n");
}
if (!err)
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH 3/7] FIX: configure disks slot for expansion
2011-03-01 14:57 ` [PATCH 3/7] FIX: configure disks slot for expansion Adam Kwolek
@ 2011-03-02 1:10 ` NeilBrown
2011-03-02 7:48 ` Kwolek, Adam
0 siblings, 1 reply; 15+ messages in thread
From: NeilBrown @ 2011-03-02 1:10 UTC (permalink / raw)
To: Adam Kwolek
Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
On Tue, 01 Mar 2011 15:57:06 +0100 Adam Kwolek <adam.kwolek@intel.com> wrote:
> 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@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
> @@ -1586,9 +1586,22 @@ 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);
> + rv = sysfs_set_num(content, dev, "slot",
> + dev->disk.raid_disk);
> + dprintf(" (status = %i)\n", rv);
> + }
> + }
> fprintf(stderr, "\n");
> }
> if (!err)
I thought I explained how this was suppose to work....
1/ Set the 'old' geometry of the array. sysfs_set_array does this.
2/ Set 'reshape_position'. sysfs_set_array does this.
3/ Set the 'new' geometry of the array. sysfs_set_array should do this but
it doesn't.
4/ Add all the disks. Repeated calls to sysfs_add_disk will do this.
5/ start the array readonly . assemble_container_content calls sysfs_set_str
to do this.
That is all.
NeilBrown
^ permalink raw reply [flat|nested] 15+ messages in thread* RE: [PATCH 3/7] FIX: configure disks slot for expansion
2011-03-02 1:10 ` NeilBrown
@ 2011-03-02 7:48 ` Kwolek, Adam
0 siblings, 0 replies; 15+ messages in thread
From: Kwolek, Adam @ 2011-03-02 7:48 UTC (permalink / raw)
To: NeilBrown
Cc: linux-raid@vger.kernel.org, Williams, Dan J, Ciechanowski, Ed,
Neubauer, Wojciech
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of NeilBrown
> Sent: Wednesday, March 02, 2011 2:10 AM
> To: Kwolek, Adam
> Cc: linux-raid@vger.kernel.org; Williams, Dan J; Ciechanowski, Ed;
> Neubauer, Wojciech
> Subject: Re: [PATCH 3/7] FIX: configure disks slot for expansion
>
> On Tue, 01 Mar 2011 15:57:06 +0100 Adam Kwolek <adam.kwolek@intel.com>
> wrote:
>
> > 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@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
> > @@ -1586,9 +1586,22 @@ 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);
> > + rv = sysfs_set_num(content, dev, "slot",
> > + dev->disk.raid_disk);
> > + dprintf(" (status = %i)\n", rv);
> > + }
> > + }
> > fprintf(stderr, "\n");
> > }
> > if (!err)
>
>
> I thought I explained how this was suppose to work....
>
> 1/ Set the 'old' geometry of the array. sysfs_set_array does this.
> 2/ Set 'reshape_position'. sysfs_set_array does this.
> 3/ Set the 'new' geometry of the array. sysfs_set_array should do this
> but
> it doesn't.
> 4/ Add all the disks. Repeated calls to sysfs_add_disk will do this.
> 5/ start the array readonly . assemble_container_content calls
> sysfs_set_str
> to do this.
>
> That is all.
>
> NeilBrown
Yes, I remember that.
I want to run correctly process first and then, I'll switch to points you specified above.
So this is not misunderstanding but work in progress /midpoint/ only ;)
BR
Adam
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 4/7] Add block_subarray()
2011-03-01 14:56 [PATCH 0/7] Grow_continue, use in assembly (cont.) Adam Kwolek
` (2 preceding siblings ...)
2011-03-01 14:57 ` [PATCH 3/7] FIX: configure disks slot for expansion Adam Kwolek
@ 2011-03-01 14:57 ` Adam Kwolek
2011-03-01 14:57 ` [PATCH 5/7] FIX: Block monitor when starting array with reshape in progress Adam Kwolek
` (3 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Adam Kwolek @ 2011-03-01 14:57 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
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@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
@@ -255,6 +255,18 @@ 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;
+}
/**
* block_monitor - prevent mdmon spare assignment
* @container - container to block
@@ -334,9 +346,7 @@ int block_monitor(char *container, const int freeze)
* takeover in reshape case and spare reassignment in the
* auto-rebuild case)
*/
- sprintf(buf, "external:%s\n", sra->text_version);
- buf[9] = '-';
- if (sysfs_set_str(sra, NULL, "metadata_version", buf))
+ if (block_subarray(sra))
break;
ping_monitor(container);
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH 5/7] FIX: Block monitor when starting array with reshape in progress
2011-03-01 14:56 [PATCH 0/7] Grow_continue, use in assembly (cont.) Adam Kwolek
` (3 preceding siblings ...)
2011-03-01 14:57 ` [PATCH 4/7] Add block_subarray() Adam Kwolek
@ 2011-03-01 14:57 ` Adam Kwolek
2011-03-01 14:57 ` [PATCH 6/7] Continue reshape after assembling array Adam Kwolek
` (2 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Adam Kwolek @ 2011-03-01 14:57 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
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@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
@@ -1528,8 +1528,10 @@ 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
@@ -27,6 +27,7 @@ extern int ack(int fd, int tmo);
extern int wait_reply(int fd, int tmo);
extern int connect_monitor(char *devname);
extern int ping_monitor(char *devname);
+extern int block_subarray(struct mdinfo *sra);
extern int block_monitor(char *container, const int freeze);
extern void unblock_monitor(char *container, const int unfreeze);
extern int fping_monitor(int sock);
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH 6/7] Continue reshape after assembling array
2011-03-01 14:56 [PATCH 0/7] Grow_continue, use in assembly (cont.) Adam Kwolek
` (4 preceding siblings ...)
2011-03-01 14:57 ` [PATCH 5/7] FIX: Block monitor when starting array with reshape in progress Adam Kwolek
@ 2011-03-01 14:57 ` Adam Kwolek
2011-03-01 14:57 ` [PATCH 7/7] FIX: array is frozen after reshape Adam Kwolek
2011-03-02 1:30 ` [PATCH 0/7] Grow_continue, use in assembly (cont.) NeilBrown
7 siblings, 0 replies; 15+ messages in thread
From: Adam Kwolek @ 2011-03-01 14:57 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
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@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
@@ -696,8 +696,21 @@ int Assemble(struct supertype *st, char *mddev,
#ifndef MDASSEMBLE
if (content != &info) {
/* This is a member of a container. Try starting the array. */
- return assemble_container_content(st, mdfd, content, runstop,
- chosen_name, verbose);
+ int err;
+ err = assemble_container_content(st, mdfd, content, runstop,
+ chosen_name, verbose);
+ if (!err) {
+ /* check if reshape of external metadata
+ * is in progress
+ * and it is need to be monitored by mdadm
+ */
+ if (content->reshape_active)
+ err = Grow_continue(mdfd, st, content,
+ backup_file);
+ }
+ close(mdfd);
+
+ return err;
}
#endif
/* Ok, no bad inconsistancy, we can try updating etc */
@@ -1518,10 +1531,9 @@ int assemble_container_content(struct supertype *st, int mdfd,
*/
sysfs_set_num(content, NULL, "sync_max", 0);
}
- if (sysfs_set_array(content, md_get_version(mdfd)) != 0) {
- close(mdfd);
+ if (sysfs_set_array(content, md_get_version(mdfd)) != 0)
return 1;
- }
+
if (content->reshape_active) {
/* set the current checkpoint to allow monitoring to
* restart reshape
@@ -1543,11 +1555,9 @@ int assemble_container_content(struct supertype *st, int mdfd,
else if (dev->disk.raid_disk >= content->array.raid_disks &&
content->reshape_active)
expansion++;
- if (working == 0) {
- close(mdfd);
+ if (working == 0)
return 1;/* Nothing new, don't try to start */
- }
-
+
map_update(&map, fd2devnum(mdfd),
content->text_version,
content->uuid, chosen_name);
@@ -1608,8 +1618,7 @@ int assemble_container_content(struct supertype *st, int mdfd,
}
if (!err)
wait_for(chosen_name, mdfd);
- close(mdfd);
- return 0;
+ return err;
/* FIXME should have an O_EXCL and wait for read-auto */
} else {
if (verbose >= 0)
@@ -1617,7 +1626,6 @@ int assemble_container_content(struct supertype *st, int mdfd,
": %s assembled with %d devices but "
"not started\n",
chosen_name, working);
- close(mdfd);
return 1;
}
}
diff --git a/Incremental.c b/Incremental.c
index 4c4b0c7..91359f4 100644
--- a/Incremental.c
+++ b/Incremental.c
@@ -1556,6 +1556,7 @@ static int Incremental_container(struct supertype *st, char *devname,
assemble_container_content(st, mdfd, ra, runstop,
chosen_name, verbose);
+ close(mdfd);
}
/* Now move all suitable spares from spare container */
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH 7/7] FIX: array is frozen after reshape
2011-03-01 14:56 [PATCH 0/7] Grow_continue, use in assembly (cont.) Adam Kwolek
` (5 preceding siblings ...)
2011-03-01 14:57 ` [PATCH 6/7] Continue reshape after assembling array Adam Kwolek
@ 2011-03-01 14:57 ` Adam Kwolek
2011-03-02 1:30 ` [PATCH 0/7] Grow_continue, use in assembly (cont.) NeilBrown
7 siblings, 0 replies; 15+ messages in thread
From: Adam Kwolek @ 2011-03-01 14:57 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
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@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
@@ -3331,6 +3331,7 @@ 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 "
@@ -3354,11 +3355,16 @@ int Grow_continue(int mdfd, struct supertype *st, struct mdinfo *info,
case 0:
dprintf(Name ": Continue bacground reshape "
"after assemblation\n");
+ forked = 1;
}
}
- return reshape_array(container, mdfd, "array", st, info, 1,
- backup_file, 0, 0, 1);
+ err = reshape_array(container, mdfd, "array", st, info, 1,
+ backup_file, 0, forked, 1);
+ if (forked)
+ unblock_subarray(info, 0);
+
+ return err;
}
diff --git a/msg.c b/msg.c
index ce2ce00..a1f4bc6 100644
--- a/msg.c
+++ b/msg.c
@@ -235,7 +235,7 @@ static char *ping_monitor_version(char *devname)
return msg.buf;
}
-static int unblock_subarray(struct mdinfo *sra, const int unfreeze)
+int unblock_subarray(struct mdinfo *sra, const int unfreeze)
{
char buf[64];
int rc = 0;
diff --git a/msg.h b/msg.h
index 090d3f6..91a7798 100644
--- a/msg.h
+++ b/msg.h
@@ -28,6 +28,7 @@ extern int wait_reply(int fd, int tmo);
extern int connect_monitor(char *devname);
extern int ping_monitor(char *devname);
extern int block_subarray(struct mdinfo *sra);
+extern int unblock_subarray(struct mdinfo *sra, const int unfreeze);
extern int block_monitor(char *container, const int freeze);
extern void unblock_monitor(char *container, const int unfreeze);
extern int fping_monitor(int sock);
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH 0/7] Grow_continue, use in assembly (cont.)
2011-03-01 14:56 [PATCH 0/7] Grow_continue, use in assembly (cont.) Adam Kwolek
` (6 preceding siblings ...)
2011-03-01 14:57 ` [PATCH 7/7] FIX: array is frozen after reshape Adam Kwolek
@ 2011-03-02 1:30 ` NeilBrown
2011-03-02 7:49 ` Kwolek, Adam
7 siblings, 1 reply; 15+ messages in thread
From: NeilBrown @ 2011-03-02 1:30 UTC (permalink / raw)
To: Adam Kwolek
Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
On Tue, 01 Mar 2011 15:56:41 +0100 Adam Kwolek <adam.kwolek@intel.com> wrote:
> 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 ++++++++++++-
> Incremental.c | 1 +
> msg.c | 18 ++++++++++++----
> msg.h | 2 ++
> 5 files changed, 81 insertions(+), 19 deletions(-)
>
I have applied the patches among these which make sense, and replied to the
ones that really don't.
If you think one of the patches that I rejected really is needed, please
provide specific detail of what you try to do, how it doesn't work, and what
you think is the reason.
All applied patches have been pushed to my devel-3.2 branch.
Thanks,
NeilBrown
^ permalink raw reply [flat|nested] 15+ messages in thread* RE: [PATCH 0/7] Grow_continue, use in assembly (cont.)
2011-03-02 1:30 ` [PATCH 0/7] Grow_continue, use in assembly (cont.) NeilBrown
@ 2011-03-02 7:49 ` Kwolek, Adam
0 siblings, 0 replies; 15+ messages in thread
From: Kwolek, Adam @ 2011-03-02 7:49 UTC (permalink / raw)
To: NeilBrown
Cc: linux-raid@vger.kernel.org, Williams, Dan J, Ciechanowski, Ed,
Neubauer, Wojciech
> -----Original Message-----
> From: NeilBrown [mailto:neilb@suse.de]
> Sent: Wednesday, March 02, 2011 2:31 AM
> To: Kwolek, Adam
> Cc: linux-raid@vger.kernel.org; Williams, Dan J; Ciechanowski, Ed;
> Neubauer, Wojciech
> Subject: Re: [PATCH 0/7] Grow_continue, use in assembly (cont.)
>
> On Tue, 01 Mar 2011 15:56:41 +0100 Adam Kwolek <adam.kwolek@intel.com>
> wrote:
>
> > 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 ++++++++++++-
> > Incremental.c | 1 +
> > msg.c | 18 ++++++++++++----
> > msg.h | 2 ++
> > 5 files changed, 81 insertions(+), 19 deletions(-)
> >
>
>
> I have applied the patches among these which make sense, and replied to
> the
> ones that really don't.
>
> If you think one of the patches that I rejected really is needed, please
> provide specific detail of what you try to do, how it doesn't work, and
> what
> you think is the reason.
>
> All applied patches have been pushed to my devel-3.2 branch.
>
> Thanks,
> NeilBrown
Thanks, I'll review your comments.
I think that patches:
FIX: Continue reshape in the background
FIX: array is frozen after reshape
and reworked:
FIX: Verify Backup file name before reshape
for fork() in Grow_continue() will be needed for container operation support.
BR
Adam
^ permalink raw reply [flat|nested] 15+ messages in thread