Re: Is there a grand plan for FC failover?

Mike Christie
2004-01-29T23:25:21Z

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