After reshape_super() call manage_reshape() should do the same things
as grow_reshape() for native metadata case (for execution on array).
The difference is on reshape finish only, when md finishes his work.
For external metadata size is managed externally from md point of view,
so specific to metadata action is required there.
This causes moving manage_reshape() placement to add necessary actions only
to common flow and not duplicate current code.
Signed-off-by: Adam Kwolek <adam.kwolek@xxxxxxxxx>
---
Grow.c | 23 +++++++++++++----------
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/Grow.c b/Grow.c
index d5f3f16..57ca66c 100644
--- a/Grow.c
+++ b/Grow.c
@@ -1799,14 +1799,6 @@ int Grow_reshape(char *devname, int fd, int quiet, char *backup_file,
break;
}
- if (st->ss->external) {
- /* metadata handler takes it from here */
- ping_manager(container);
- st->ss->manage_reshape(st, backup_file);
- frozen = 0;
- break;
- }
-
/* set up the backup-super-block. This requires the
* uuid from the array.
*/
@@ -1877,6 +1869,15 @@ int Grow_reshape(char *devname, int fd, int quiet, char *backup_file,
d - odisks, fdlist+odisks, offsets+odisks);
if (backup_file && done)
unlink(backup_file);
+
+ /* manage/finalize reshape in metadata specific way
+ */
+ close(fd);
+ if (st->ss->external && st->ss->manage_reshape) {
+ st->ss->manage_reshape(st, backup_file);
+ break;
+ }
+
if (level != UnSet && level != array.level) {
/* We need to wait for the reshape to finish
* (which will have happened unless odata < ndata)
@@ -1887,8 +1888,10 @@ int Grow_reshape(char *devname, int fd, int quiet, char *backup_file,
if (c == NULL)
exit(0);/* not possible */
- if (odata < ndata)
- wait_reshape(sra);
+ /* child process has always wait for reshape finish
+ * to perform unfreeze
+ */
+ wait_reshape(sra);
err = sysfs_set_str(sra, NULL, "level", c);
if (err)
fprintf(stderr, Name ": %s: could not set level to %s\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
