Re: Improving geom_mirror(4)'s read balancing

Maxim Sobolev wrote:
> Ivan Voras wrote:
>> Maxim Sobolev wrote:
>>
>>> The patch is available here:
>>> http://sobomax.sippysoft.com/~sobomax/geom_mirror.diff. I would like to
>>> get input on the functionality/code itself, as well on what is the best
>>> way to add this functionality. Right now, it's part of the round-robin
>>> balancing code. Technically, it could be added as a separate new
>>> balancing method, but for the reasons outlined above I really doubt
>>> having "pure" round-robin has any practical value now. The only case
>>> where previous behavior might be beneficial is with solid-state/RAM
>>> disks where there is virtually no seek time, so that by reading close
>>> sectors from two separate disks one could actually get a better speed.
>>> At the very least, the new method should become default, while "old
>>> round-robin" be another option with clearly documented shortcomings. I
>>> would really like to hear what people think about that.
>>
>> Have you perhaps seen this:
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113885
>>
>> I'm using the patch in the PR and it helps a bit, similar to what you
>> have seen. Pawel is silent about the issue so I guess it can also be
>> taken as silent approval :)
> 
> Oh, great! I am curious as to if there is any background behind
> "distance to use delay" metric? 

I thought it's very similar to what you did - it attempts to send BIOs
to the drive whose head is "closest" to the last position, but attempts
to use time instead of area covered by the head. (if I'm reading it
correctly).

> To me it seems the current number of
> outstanding requests is much more important when selecting between disk
> X and disk Y. I am not a storage expert, so that I could be wrong
> though. One way or another the load-balancing has be improved and the
> new more intelligent scheduling IMHO should be the default one.

I agree.

I currently don't have any systems on which I could test this. Can you
try both variants and see if there's any change? Can you try running
randomio and "diskinfo -vt" on the gmirror volume? Diskinfo should give
one interesting result - with a proper patch and with two drives it
should reduce full stroke to sequential.