From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wen Congyang Subject: Re: [RFC Patch v3 15/18] support blktap remus in xl Date: Wed, 10 Sep 2014 18:36:41 +0800 Message-ID: <541029B9.1020602@cn.fujitsu.com> References: <1409908261-18682-1-git-send-email-wency@cn.fujitsu.com> <1409908261-18682-16-git-send-email-wency@cn.fujitsu.com> <1410176385.10156.199.camel@kazak.uk.xensource.com> <540FFB70.5050003@cn.fujitsu.com> <1410343475.8217.287.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1410343475.8217.287.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Lai Jiangshan , Ian Jackson , Jiang Yunhong , Dong Eddie , xen devel , Shriram Rajagopalan , Yang Hongyang List-Id: xen-devel@lists.xenproject.org At 09/10/2014 06:04 PM, Ian Campbell Write: > On Wed, 2014-09-10 at 15:19 +0800, Wen Congyang wrote: >> At 09/08/2014 07:39 PM, Ian Campbell Write: >>> NB, this series was presented as "Some bugfix patches". I think we are >>> way out of that territory and into feature land. >>> >>> On Fri, 2014-09-05 at 17:10 +0800, Wen Congyang wrote: >>>> With this patch, we can use blktap remus like this: >>>> disk = [ 'format=remus,devtype=disk,access=w,vdev=hda,backendtype=tap,target=192.168.3.1:9000|aio:filename' ] >>> >>> I don't think it makes sense to wedge remus in as a kind of pseudo >>> format as you've done here, but I'm not really sure what the actual >>> right answer is. I suspect some sort of remus specific field or cfg file >>> option. Perhaps ",remus=192.168...,target=filename". >> >> What about this: "format=raw,backendtype=tap,filter=remus, filter-params=192.168...,target=filename"? > > I don't know, because you've not defined what a "filter" is as an > abstract concept i.e. what else might it be used for, so I don't know > why we would prefer it to just remus= as a toplevel thing. blktap2 accepts such params: [driver:params|]driver:params The last driver should be aio/vhd, and the params should be the filepath/devpath. Only the last drvier operates the file/device. I call the first driver filter driver. All I/O request will be sent to filter driver first, the filter driver can do anything(for example, log, block...). After this, the I/O reqeust will be forwarded to last driver. The first driver can be cache, log, remus, or colo(implemented in another patchset)... If we use "remus=", I think we should support "log=", "cache=", "colo="... Too many keys... Thanks Wen Congyang > > Ian. > > . >