Re: fr1-2.16 patch for 2.6.10 kernel

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