Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support.(RFC)

[Dan Smith <danms@xxxxxxxxxx>]

IP> Yep, dm-userspace is certainly going to need to have a way of
IP> intercepting IO completions and then choosing when it's actually
IP> going to propagate the completion to the backend. That's quite a
IP> big change to the current code (incidentally, the dm-snap code is
IP> pretty shocking in this respect too).

I'm not sure if I agree that it will be a big change.  It's going to
require keeping track of a few additional states for each remap, as
well as a couple more message types.  Hijacking the callback function
of each request is done quite a bit in the rest of the block
subsystem.  My testing shows that communication between kernel and
userspace for the additional handshaking will not add significant
additional overhead.  Definitely some work, but not a huge change,
IMHO.

IP> It doesn't bypass the buffer cache (so all bets are off for data
IP> integrity) and can end up consuming all of dom0 memory with dirty
IP> buffers -- just create a few loop devices and do a few parallel
IP> dd's to them and watch the oomkiller go on the rampage. It's even
IP> worse if the filesystem the file lives on is slow e.g. NFS.

Ok, it seems like this should be addressed in the upstream loop
driver.  I imagine quite a few people are depending on the loop driver
right now, expecting it to maintain data integrity.

Could the loop driver make use of the routines that do direct IO
instead of the normal routines to solve this when it's an issue?

This brings me to another question: Will people really be using
file-based images for their VMs?  It seems to me that the performance
of using a block device overshadows the convenience of a file image.

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@xxxxxxxxxx

Attachment: pgpjE85w1nxBb.pgp
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel