On Tue, Dec 19, 2000 at 04:56:40PM +0100, Jakob =D8stergaard wrote: > You know more about this stuff than most, I'm sure. Do you think that > such heuristic could be added without being vendor/model/moonphase sp= ecific ? To go safe and simple we could only consider forward seeks to make sure= not to get fooled by disks that are slower during backward seeks than forward = seeks. But I now see the point of looking backwards. Supposed there's an mmapp= ed io that generates page faults back and forth, we want to keep one single d= isk serving such mmapped-io even when it goes backwards. So if there are tw= o of those mmapped-io at the same time and there are two disks, each disk wi= ll serve its requests. If we consider only forward seeks then we could invalidate the above ca= se, and introducing a penality factor for backwards seeks is messy as you s= ay... > > 3) this fast path check is wrong, if the check returns true it mean= s > > the disk will do a seek backwards while there could be another d= isk > > that could read the block without any seek > >=20 > > + if( this_sector =3D=3D conf->mirrors[new_disk].current_position ) > > + goto rb_out; >=20 > What ? No, you're wrong. .current_position is where the head is at, I overlooked the + sector indeed :), sorry. Previously I only read it o= nce and fast in mozilla. I will integrate the patch now that it's clear what's doing. Thanks for the comments. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-raid" i= n the body of a message to [EMAIL PROTECTED]
