From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jun'ichi Nomura" Subject: Re: [k-ueda@ct.jp.nec.com: Re: request-based dm-multipath] Date: Fri, 17 Apr 2009 18:46:36 +0900 Message-ID: <49E84FFC.3050709@ce.jp.nec.com> References: <20090410151914.GA3800@redhat.com> <20090410153102.GC3800@redhat.com> <20090415201829.GB9064@redhat.com> <49E6FAC5.2080807@ce.jp.nec.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Mikulas Patocka Cc: Kiyoshi Ueda , Mike Snitzer , dm-devel@redhat.com, Michael Christie , agk@redhat.com List-Id: dm-devel.ids 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