Re: Is there a grand plan for FC failover?

[Mike Christie <mikenc@us.ibm.com>]

James Bottomley wrote:
> On Thu, 2004-01-29 at 10:24, Philip R. Auld wrote:
> 
>>I think the place to do load balancing would be below the block queue so that
>>the IOs are coalesced. IMO, until you've merged the individual block requests 
>>you can't make a good decision about how to balance the load. 
> 
> 
> Yes, that's what I think too, so the elevator should go above dm, with a
> vestigial elevator between dm and sd simply for SCSI to use in queuing.


I do not think there is anyone that will disagree that there should be 
one elevator that does the sorting, merging, aging etc and that it 
should be at a different layer than it is today for DM multipath.

The modifications to DM to allow a multipath device to have a queue and 
to use it are minial. The problem is it's request_fn_proc. In the DM 
request_fn_proc we could just dequeue a request from the DM device's 
queue, clone it so the IO sched state does not get overwritten, map it 
to the correct lower level device queue, then insert it in the lower 
level device queue. Bad design right? We could do something similar 
where the request_fn_proc recieves a request instead of a queue like 
Jen's is planning for 2.7 
(http://www.kernel.org/pub/linux/kernel/people/axboe/experimental/), and 
then build a framework similar to bio remapping where we just clone and 
remap requests to the correct driver. But still a bad design right?

It doesn't seem like there are a lot of options for 2.6 with the current 
framework. We can add hints so we can try to make a decent decsion, but 
it isn't going to be perfect. But as James said the elevator problem is 
not a requirement for dm to actually work. I guess people will continue 
rolling their own solution if they feel the performance is that bad.

I cc'd Jens as he is best qualified to describe why there are problems 
with queueing requests between different queue's. I apoligize for 
bugging him about this again.


Mike