From: Neil Brown <neilb@suse.de>
To: "Czarnowska, Anna" <anna.czarnowska@intel.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
"Neubauer, Wojciech" <Wojciech.Neubauer@intel.com>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"Ciechanowski, Ed" <ed.ciechanowski@intel.com>,
"Labun, Marcin" <Marcin.Labun@intel.com>,
"Hawrylewicz Czarnowski,
Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@intel.com>
Subject: Re: Devel 3.2 branch issues
Date: Tue, 23 Nov 2010 11:52:13 +1100 [thread overview]
Message-ID: <20101123115213.3664ec27@notabene.brown> (raw)
In-Reply-To: <A9DE54D0CD747C4CB06DCE5B6FA2246F010BF03CC6@irsmsx504.ger.corp.intel.com>
On Mon, 22 Nov 2010 22:39:00 +0000
"Czarnowska, Anna" <anna.czarnowska@intel.com> wrote:
>
> > by the way, some of the changes in you of the patches you sent have not
> > been
> > included in any form. They include:
> >
> > - the getinfo_super_disks method. I couldn't see why you need this.
> > All the
> > info about the state of the arrays should already be available.
> > If there is something that you need that we don't have, please
> > explain and
> > we can see how best to add it back in.
>
> Marcin has already answered this but here is my explanation.
> Current test devstate[i]==0 is always true for container so any device seems a good candidate to move.
> To be able to identify members, failed devices and real spares we updated devstate for containers.
> To find members we can just check which disks are used in subarrays, but a failed disk is removed from subarray after a short while and as soon as it happens we are not able to see a difference between the failed disk and a spare unless we look at metadata.
Thanks. That makes sense. I'll look at the code and see about applying it.
>
> > - min_active_disk_size_in_array. I don't think the minimum current
> > size is
> > really a good guide. I've kept the code for letting the metadata
> > handler
> > check the size, but anything beyond that should be done with domains
> > I
> > think.
> > E.g have a domain '2G-or-greater' which is assigned to all 2G or
> > greater
> > devices. Then anything smaller will automatically be excluded from
> > arrays
> > with those devices.
>
> So if someone doesn't base domains on size they may have a small spare added to an array where it cannot be used.
> Min_active_disk_size was more than required for an array that didn't occupy the whole disk but at least it ensured that we are not throwing in something that wouldn't help. If we do this the array will remain degraded but will have spare - so Monitor may think it does not need more.
> For this reason we also checked the case when there was a spare in "to" container. If the spare was not suitable (size check here too) we would still look for a good one.
I don't think it is possible to come up with an automatic way to determine if
a given spare suits a given array that is always correct. There are too many
subtleties.
So I would like to allow the sysadmin to exercise complete control, and have
defaults that make reasonable sense in common cases.
The 'complete control' can be exercised through domain - though I will
probably add some size based rule mechanism to the policy code so devices can
be categorised by size if wanted.
The 'safe default' is probably best left to the metadata handler. So
ultimately all metadata types *should* specify min_acceptable_spare_size,
and we will just make do with that.
Does that sound OK?
>
> And now back to assembly. There is still a segmentation fault when we try to assemble a subarray. Occurs when there is any config file and we run "mdadm -As" or "mdadm -Asc /etc/mdadm.conf". content is NULL when we try to compare uuid in line 413 in Assemble.c.
Yes - patch below should fix this.
> We are going to prepare some tests to add to current suite so it will be easier to verify new patches.
That would be greatly appreciated!!
Thanks,
NeilBrown
commit 87477e6d5e4201bf2bd812f34f8321983310bd99
Author: NeilBrown <neilb@suse.de>
Date: Tue Nov 23 11:34:36 2010 +1100
Assemble: get content before testing it.
When checking that a container matches the required uuid,
we need to call 'getinfo_super' before we have a 'content'
to test.
Reported-by: "Czarnowska, Anna" <anna.czarnowska@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
diff --git a/Assemble.c b/Assemble.c
index 1a1e128..607f2af 100644
--- a/Assemble.c
+++ b/Assemble.c
@@ -409,6 +409,11 @@ int Assemble(struct supertype *st, char *mddev,
if (ident->container[0] != '/') {
/* we have a uuid */
int uuid[4];
+
+ content = &info;
+ memset(content, 0, sizeof(*content));
+ tst->ss->getinfo_super(tst, content, NULL);
+
if (!parse_uuid(ident->container, uuid) ||
!same_uuid(content->uuid, uuid, tst->ss->swapuuid)) {
if (report_missmatch)
next prev parent reply other threads:[~2010-11-23 0:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-22 22:39 Devel 3.2 branch issues Czarnowska, Anna
2010-11-23 0:52 ` Neil Brown [this message]
2010-11-23 12:04 ` Czarnowska, Anna
2010-11-25 8:01 ` Neil Brown
2010-11-25 10:28 ` Czarnowska, Anna
2010-11-26 18:23 ` Czarnowska, Anna
2010-11-28 22:59 ` Neil Brown
-- strict thread matches above, loose matches on Subject: below --
2010-10-29 14:13 [Patch 00/17] Autorebuild Czarnowska, Anna
2010-11-17 10:22 ` Neil Brown
2010-11-18 23:14 ` Czarnowska, Anna
2010-11-19 12:43 ` Devel 3.2 branch issues Czarnowska, Anna
2010-11-22 3:29 ` Neil Brown
2010-11-22 17:18 ` Labun, Marcin
2010-11-22 18:47 ` Dan Williams
2010-11-23 17:34 ` 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=20101123115213.3664ec27@notabene.brown \
--to=neilb@suse.de \
--cc=Marcin.Labun@intel.com \
--cc=Wojciech.Neubauer@intel.com \
--cc=anna.czarnowska@intel.com \
--cc=dan.j.williams@intel.com \
--cc=ed.ciechanowski@intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=przemyslaw.hawrylewicz.czarnowski@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).