| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support. (RFC
Wonderful!! Now we have dm-userspace and blktap, and these two seems
to do the similar things. So what are the pros/cons of blktap compared
to dm-userspace?
I'm sure that Dan can comment on this as well. The main technical
difference is that (as I understand it at least) dm-userspace doesn't
bring block data through userspace, just the block request addresses,
which may be redirected. The current tap code maps the entire request
up, so you can potentially change the data and you can issue block I/O
using normal unix file access functions.
My intuition is that an approach like dm-userspace can be made more
efficient in the long run, but right now it's going to be slower as
you need to do copies of guest data pages as requests go through the
device mapper kernel code. This should be fixable though. I'm also
not sure how carefully dm-u watches block completion responses to
ensure safety of metadata updates relative to data writes. This too
should be fixable -- i just don't know if the user-level tools can
currently request completion notifications on requests that they've
processed. A benefit to the dm-user patch is that it is more of a
linux approach than a xen+linux approach. Dm-user will be generally
useful in the linux tree, whereas our stuff takes advantage of
Xen-specific things to get high performance (i.e. zero-copy data
movement).
dm-user also has the benefit of being able to map images directly in
dom0, which is very useful for tools and is something we haven't yet
added. Similarly though, one downside of dm-user, that is absolutely
no fault of the developers, is the dependency on the linux loopback
driver which has some bad failure characteristics which can result in
both data being acknowledged as written even though it hasn't been,
and the OOM killer going insane. I think some fixes to loop probably
need to be applied in the near future given how much people are
generally depending on the code with VMs.
Blktap is a bit of a bigger hammer -- requests are moved to userspace
and the current backends do everything there. This gives you a lot
more flexibility in terms of developing virtual block devices. Take a
look at tools/blktap_user/block-*.c to see what plugins look like,
they're pretty tidy imo. ;) The current code has the immediate benefit
of being fully integrated with the tools and so on, so should be easy
to play with and extend. Having access to block contents also makes
it possible to do things like compression, encryption,
content-adressable storage, and memory-backed block devices.
I suspect that the ideal answer lies somewhere in between the two.
Julian and I have talked about extending the tap driver to combine it
with blkback and allow block address translation without access to
request contents.
That's my biased view ;) -- I'm sure Dan can clear things up a bit.
Now that we have this code to the list, Julian and I are hoping to
take a closer look at dm-user and get a better sense of the relative
merits of the two approaches.
a.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home