Re: [k-ueda@ct.jp.nec.com: Re: request-based dm-multipath]

["Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>]

Mikulas Patocka wrote:
> On Thu, 16 Apr 2009, Jun'ichi Nomura wrote:
>> The main purpose of request-based dm patches is to provide a framework
>> to implement optimal path selectors in non-intrusive way.
>>
>> As you mentioned, it might be possible to implement a good path
>> selector at bio-level by checking internals of underlying devices' 
>> request queues and/or I/O schedulers.
>>
>> However, requiring knowledge/assumptions of internals of other layer
>> is not a right approach.
> 
> There is also a number of functions that any driver can call on queue to 
> access the queue state (see blkdev.h).
> 
> So if you add one more function (something like 
> blk_queue_can_merge_at_this_point(struct request_queue *, sector_t), 
> there's nothing wrong about it, it's much less intrusive than adding an 
> alternate i/o path.

And it means exposing the I/O scheduler internal to let
the path selector guess its behavior, which is what I would like to avoid.

I think existing block layer interfaces are not doing that.


>> Or, splitting the request-based multipath driver out of dm would trash
>> the existing userspace tools and libraries, so that's not good either.
>> Thus we chose the design of 'adding request-based mapping feature to dm'.
>> It doesn't break existing target drivers and userspace tools.
>> The feature is enabled only for request-based target drivers.
>> If you want to add a bio-specific new feature, it's still possible.
> 
> I don't want to pull multipath out of dm. I want it to use the standard 
> i/o path in dm.
> 
> I am convinced that the path balacing can be solved without using 
> requests.

The point is not about 'can' or 'cannot'.

My point is that by adding the request-based mapping interface,
path selectors can be implemented in a clean and maintainable way.


Thanks,
-- 
Jun'ichi Nomura, NEC Corporation