Re: [Xen-devel] [RFC Patch v3 15/18] support blktap remus in xl

[Wen Congyang <wency@xxxxxxxxxxxxxx>]

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.
> 
> .
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel