-----Original Message-----
From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
owner@vger.kernel.org] On Behalf Of Neil Brown
Sent: Thursday, November 25, 2010 9:02 AM
To: Czarnowska, Anna
Cc: linux-raid@vger.kernel.org; Neubauer, Wojciech; Williams, Dan J;
Ciechanowski, Ed; Labun, Marcin; Hawrylewicz Czarnowski, Przemyslaw
Subject: Re: Devel 3.2 branch issues

On Tue, 23 Nov 2010 11:52:13 +1100 Neil Brown [off-list ref] wrote:

quoted

On Mon, 22 Nov 2010 22:39:00 +0000
"Czarnowska, Anna" [off-list ref] wrote:

quoted

quoted

by the way, some of the changes in you of the patches you sent

have not

quoted

quoted

quoted

been
included in any form.  They include:

- the getinfo_super_disks method.  I couldn't see why you need

this.

quoted

quoted

quoted

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.

quoted

quoted

To be able to identify members, failed devices and real spares we

updated devstate for containers.

quoted

quoted

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.

quoted

Thanks.  That makes sense.  I'll look at the code and see about

applying it.

quoted

OK, I have something, though I haven't tested it.

It uses your getinfo_super_disks and does the following to choose a
spare
from an external array.  There are a couple of rearrangement patches
before
this so it won't apply as-it, but should appear in my devel-3.2 within
a few
hours.

NeilBrown

Well, this didn't help. 
In the set of tests I have just posted even the basic ones fail for imsm.
For native there are still some problems with tests:
 5c - spare not moved to degraded array in the same domain. This is really basic test with 4 arrays instead of 2.
 9 - spare moved between different metadata arrays
13 - spare moved despite action=include which doesn't allow migration

Test9 run in scan mode generates a segmentation fault.

I will have a look at this in debugger and give you more info on the reasons later on.

Anna

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.