From: NeilBrown <neilb@suse.de>
To: "Labun, Marcin" <Marcin.Labun@intel.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [PATCH] kill-subarray: fix, IMSM cannot kill-subarray with unsupported metadata
Date: Tue, 1 Nov 2011 15:48:07 +1100 [thread overview]
Message-ID: <20111101154807.0cf42aa5@notabene.brown> (raw)
In-Reply-To: <F9123E44003394499FDD2B17C60621D4043D80@IRSMSX101.ger.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 8231 bytes --]
On Mon, 31 Oct 2011 16:52:22 +0000 "Labun, Marcin" <Marcin.Labun@intel.com>
wrote:
>
>
> > -----Original Message-----
> > From: NeilBrown [mailto:neilb@suse.de]
> > Sent: Monday, October 31, 2011 1:32 AM
> > To: Labun, Marcin
> > Cc: linux-raid@vger.kernel.org; Williams, Dan J
> > Subject: Re: [PATCH] kill-subarray: fix, IMSM cannot kill-subarray with
> > unsupported metadata
> >
> > On Fri, 28 Oct 2011 14:46:57 +0000 "Labun, Marcin"
> > <Marcin.Labun@intel.com>
> > wrote:
> >
> > > Hi Neil,
> > > Please review modified patch in response for your comments.
> > > I have introduced two flags, one for activation blocking, second for
> > > container wide reshapes
> > > Blocking:
> > > - some arrays in container are blocked, the others can be activated
> > > and reshaped,
> > > - some arrays are blocked, others can be activated but container wide
> > reshaped is blocked for all.
> > >
> > > Thanks,
> > > Marcin Labun
> >
> > Thanks. This looks mostly OK.
> > I have applied it - with a number of formatting improvements and the
> > removal for a debugging printf :-)
>
> Thanks!
> It seems that map_lock call appeared from *nowhere* in the modified patch :). Please see the context below.
Thanks for checking and noticing that.
It was a merge error on my part. As your patch added a map_unlock call I
reasoned that the map_lock call which you patch left unchanged needed to be
added back - I obviously wasn't thinking clearly.
I have removed it and the map_unlock that your patch added.
>
> - /* do not assemble arrays that might have bad blocks */
> - if (list && list->array.state & (1<<MD_SB_BBM_ERRORS)) {
> - fprintf(stderr, Name ": BBM log found in metadata. "
> - "Cannot activate array(s).\n");
> - /* free container data and exit */
> - sysfs_free(list);
> - return 2;
> - }
> -
> + /* when nothing to activate - quit */
> + if (list == NULL)
> + return 0;
> + if (map_lock(&map))
> + fprintf(stderr, Name ": failed to get exclusive lock on "
> + "mapfile\n");
>
> >
> > However this bit looks wrong:
> >
> > > +/*
> > > + * helper routine to check metadata reshape avalability
> > > + * 1. Do not "grow" arrays with volume activation blocked
> > > + * 2. do not reshape containers with container reshape blocked
> > > + *
> > > + * IN:
> > > + * subarray - array name or NULL for container wide reshape
> > > + * content - md device info from container_content
> > > + * OUT:
> > > + * 0 - block reshape
> > > + */
> > > +static int check_reshape(char *subarray, struct mdinfo *content) {
> > > + char *ep;
> > > + unsigned int idx;
> > > + printf("subarray: %s\n", subarray);
> > > +
> > > +
> > > + if (!subarray) {
> > > + if (content->array.state &
> > (1<<MD_SB_BLOCK_CONTAINER_RESHAPE))
> > > + return 0;
> > > + }
> > > + else {
> > > + /* do not "grow" arrays with volume activation blocked */
> > > + idx = strtoul(subarray, &ep, 10);
> > > + if ((*ep == '\0') && (content->container_member == (int)
> > idx) &&
> > > + (content->array.state & (1<<MD_SB_BLOCK_VOLUME)))
> > > + return 0;
> > > + }
> > > +
> > > + return 1;
> > > +}
> >
> > Grow.c shouldn't be doing a 'strtoul' here. The subarray string
> > belongs to the metadata handler, mdadm core code shouldn't interpret it
> > at all.
> >
> > What exactly is the point of that bit of code?
> >
> > Thanks,
> > NeilBrown
> Grow.c generates subarray string in super_by_fd() function.Derived from (struct mdinfo) sra->text_version.
>
> In check_reshape function I want to know on which subarray grow operates to get subarray blocking bits.
I think I see - thanks.
I have changed the code to do what I think it should. Please review patch
below.
Thanks,
NeilBrown
commit 446894ea8db17a2dfc740f81d58190c5ac8167d5
Author: NeilBrown <neilb@suse.de>
Date: Tue Nov 1 15:45:46 2011 +1100
Grow: fix check_reshape and open_code it.
check_reshape should not try to parse the subarray string - only
metadata handlers are allowed to do that.
The common code and only interpret a subarray string by passing it to
"container_content" which will then return only the member for that
subarray.
So remove check_reshape and place similar logic explicitly at the two
call-sites. They are different enough that it is probably clearer to
have explicit code.
Signed-off-by: NeilBrown <neilb@suse.de>
diff --git a/Grow.c b/Grow.c
index 598fd59..8df4ac4 100644
--- a/Grow.c
+++ b/Grow.c
@@ -1358,36 +1358,6 @@ static int reshape_container(char *container, char *devname,
char *backup_file,
int quiet, int restart, int freeze_reshape);
-/*
- * helper routine to check metadata reshape avalability
- * 1. Do not "grow" arrays with volume activation blocked
- * 2. do not reshape containers with container reshape blocked
- *
- * IN:
- * subarray - array name or NULL for container wide reshape
- * content - md device info from container_content
- * OUT:
- * 0 - block reshape
- */
-static int check_reshape(char *subarray, struct mdinfo *content)
-{
- char *ep;
- unsigned int idx;
-
- if (!subarray) {
- if (content->array.state & (1<<MD_SB_BLOCK_CONTAINER_RESHAPE))
- return 0;
- } else {
- /* do not "grow" arrays with volume activation blocked */
- idx = strtoul(subarray, &ep, 10);
- if (*ep == '\0'
- && content->container_member == (int) idx
- && (content->array.state & (1<<MD_SB_BLOCK_VOLUME)))
- return 0;
- }
- return 1;
-}
-
int Grow_reshape(char *devname, int fd, int quiet, char *backup_file,
long long size,
int level, char *layout_str, int chunksize, int raid_disks,
@@ -1505,12 +1475,16 @@ int Grow_reshape(char *devname, int fd, int quiet, char *backup_file,
cc = st->ss->container_content(st, subarray);
for (content = cc; content ; content = content->next) {
- int allow_reshape;
+ int allow_reshape = 1;
/* check if reshape is allowed based on metadata
* indications stored in content.array.status
*/
- allow_reshape = check_reshape(subarray, content);
+ if (content->array.state & (1<<MD_SB_BLOCK_VOLUME))
+ allow_reshape = 0;
+ if (content->array.state
+ & (1<<MD_SB_BLOCK_CONTAINER_RESHAPE))
+ allow_reshape = 0;
if (!allow_reshape) {
fprintf(stderr, Name
" cannot reshape arrays in"
@@ -3788,10 +3762,10 @@ int Grow_continue_command(char *devname, int fd,
goto Grow_continue_command_exit;
}
- cc = st->ss->container_content(st, NULL);
+ cc = st->ss->container_content(st, subarray);
for (content = cc; content ; content = content->next) {
char *array;
- int allow_reshape;
+ int allow_reshape = 1;
if (content->reshape_active == 0)
continue;
@@ -3800,10 +3774,14 @@ int Grow_continue_command(char *devname, int fd,
* content->reshape_active state, therefore we
* need to check_reshape based on
* reshape_active and subarray name
- */
- allow_reshape =
- check_reshape((content->reshape_active == CONTAINER_RESHAPE)? NULL : subarray,
- content);
+ */
+ if (content->array.state & (1<<MD_SB_BLOCK_VOLUME))
+ allow_reshape = 0;
+ if (content->reshape_active == CONTAINER_RESHAPE &&
+ (content->array.state
+ & (1<<MD_SB_BLOCK_CONTAINER_RESHAPE)))
+ allow_reshape = 0;
+
if (!allow_reshape) {
fprintf(stderr, Name
": cannot continue reshape of an array"
diff --git a/super-intel.c b/super-intel.c
index 1caee70..34a4b34 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -5759,8 +5759,8 @@ static struct mdinfo *container_content_imsm(struct supertype *st, char *subarra
map->num_members, /* raid disks */
&chunk,
1 /* verbose */)) {
- fprintf(stderr, Name ": IMSM RAID gemetry validation failed. "
- "Array %s activation is blocked.\n",
+ fprintf(stderr, Name ": IMSM RAID geometry validation"
+ " failed. Array %s activation is blocked.\n",
dev->volume);
this->array.state |=
(1<<MD_SB_BLOCK_CONTAINER_RESHAPE) |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2011-11-01 4:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-28 14:46 [PATCH] kill-subarray: fix, IMSM cannot kill-subarray with unsupported metadata Labun, Marcin
2011-10-31 0:31 ` NeilBrown
2011-10-31 16:52 ` Labun, Marcin
2011-11-01 4:48 ` NeilBrown [this message]
2011-11-03 15:23 ` Labun, Marcin
2011-11-07 1:34 ` NeilBrown
2011-11-10 10:00 ` Labun, Marcin
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=20111101154807.0cf42aa5@notabene.brown \
--to=neilb@suse.de \
--cc=Marcin.Labun@intel.com \
--cc=dan.j.williams@intel.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.