[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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=|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 
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...). 
this, the I/O reqeust will be forwarded to last driver.

The first driver can be cache, log, remus, or colo(implemented in another 
If we use "remus=", I think we should support "log=", "cache=", "colo="...
Too many keys...

Wen Congyang

> Ian.
> .

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.