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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
