[dm-devel] Re: [k-ueda at ct.jp.nec.com: Re: request-based dm-multipath]
Jun'ichi Nomura
j-nomura at ce.jp.nec.com
Fri Apr 17 09:46:36 UTC 2009
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
More information about the dm-devel
mailing list