Re: [Patch 00/17] Autorebuild

[Neil Brown <neilb@suse.de>]

On Mon, 22 Nov 2010 15:08:27 +0000
"Czarnowska, Anna" <anna.czarnowska@intel.com> wrote:

> > > 4. With spare-same-slot when there is a cookie and disk has no
> > metadata then we probably shouldn't look at domains. Just add.
> > >
> > 
> > I disagree.  We must always check domains.
> > Why do you think we should ignore domains in that case?
>  
> Easy example is: we have an array made on two disks sda and sdb.
> Sda has domain d1. Sdb has domain d2. This is perfectly ok for Create.
> Now sdb fails and we put a new disk in that place. It gets domain d2 because it is in the same slot as old disk.
> When the array went degraded and sdb was removed, the domain for the array was reduced to d1 only.
> New disk does not match any more so it is not added.
> 
> I think we should still add it because we have a file saying that this slot belongs to that array.
> There is also controller domain that has the special meaning but I don't think it is a problem.
> If the user originally created the array spanning different controllers why wouldn't we take a replacement occupying the same slot as original member?
> 
> My conclusion is: we should ignore domains when there is a cookie.

Yes, that make sense.  Thanks for the explanation.

So when we find a device with a cookie file that identifies a particular
array, we allow that device to be added to that array without further
reference to domain.
Sounds good.  It should go in the man-page somewhere of course.

> 
> Note that we don't look at domains at all when we add a disk with spare metadata. Here it is indeed very much needed.
> When someone creates some arrays and adds some spares, additionally defines domains to keep all related disks together, then he may be disappointed seeing that after reboot all spares end up in one container anyway. This happens for imsm and because of this issue some spare that was meant for a different array may be used in the first array from config instead (all spares will be added there regardless of domains).
> 

Presumably is required for both -I and -A.
Normally when assembling an array we ignore domains because if two devices
claim to be in an array, then they need to be assembled together no matter
what domains say.
But for truly global spares, the metadata doesn't tell us much, so we only
add such a spare to an array for which the domain says it is OK.

This is a little awkward for -I as if we get a spare first we have no idea
what to do with it.
I think we had an idea once of having a container for global spares.  We
could proceed with that, putting spares in that container as they are found.
and maybe have Monitor() move these spares to an active container if one is
found with a domain match.  Maybe?

NeilBrown



> 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.