Re: Re: fr1-2.16 patch for 2.6.10 kernel

Peter T. Breuer a écrit :
> In article <[email protected]> you wrote:
> 
>>denis bonnenfant a ?crit :
>>I can't really see why the new read_balance() will not do the job 
>>correctly in case of an fr1 array,
> 
> 
> Because it does NOT do the right thing - neither did the old "map()", but
> it could be changed to pick the next disk instead of disk 0 the whole
> time, because it was used nowhere else.
> 
> Now if we change read_balance, we mess the ordinary behaviour up. So
> "Don't Do That Then" - put back map() instead and all will be well!
> 
> 
>>as we are not manipulating the 
>>bitmap.
> 
> 
> Neither is associated with the bitmap.
> 
> 
>>It seems to be protected from balancing if a resync is in 
>>progress, so i don't see why not using it as is. 
> 
> 
> Because it doesn't do the right thing.
> 
> 
>>Maybe I missed something ?
> 
> 
> :-). The aim here is to try the next disk after a read failure.

So why not rename map() with with a new read_next() function, for 
example that do exactly what we want, and get rid of map() ? It may be 
less confusing and simpler to maintain. Or coding this directly in 
raid1d in place of read_balance call ?

> Read_balance will just choose the _best_ disk (in its own terms, which
> are to do with the calculated head position, or similar nonsense - IMHO,
> of course), and that will be the same disk after a failed read as just
> before a failed read, at present!  So it certainly needs changing.  But
> it can't be changed, as it is used in ordinary operation too.  So one
> should not use it.
> 
> Well, you could try, but it would be relying on chance. Hmm .... maybe
> you could set the calculated head position for the disk with the failed
> read to something cmpletely absurd? But then you are in danger of
> cycling with two failed disks.
> 
> Peter
> _______________________________________________
> ENBD mailing list
> [email protected]
> http://lists.community.tummy.com/mailman/listinfo/enbd