Patch 2 of 3. Signed-off-by: Jake Wires <jake.wires@citrix.com>, Dutch Meyer <dmeyer@cs.ubc.ca> This is a new and rewritten version of blktap that we have developed at Citrix. The current version of blktap is left functionally unmodified. The change set consists of three patches. 0) A patch to deprecate the open source blktap, by moving it and issuing a warning whenever it is used. No functionality is modified in this patch, it is just housekeeping. 1) A patch to add a new blktap implementation that is feature equivalent to (or better than) the current open source blktap. This will eventually replace the current blktap implementation. 2) Fix several bugs in the qcow tools. 3) A kernel patch to add a new unified blktap2 module that will eventually replace blktap. The new blktap implementation has several improvements. * Isolation from xenstore - Blktap devices can now be created in dom0 as virtual block devices without coordination from xen and have few dependencies on xenstore in normal operation. * Improved development environment for tapdisks, simpler request forwarding, new request scheduler. * Pause scripts updated to support live qcow snapshot (see xmsnap script) * New tapdisk type: Block Mason disks allow a set of tapdisks to be flexibly arranged into graph structure and modified on-the-fly. Several example modules for Block Mason are included. Block Mason disks are constructed and modified with a declarative configuration language. These capabilities are discussed in more depth in an upcoming paper in the First Workshop on IO Virtualization, available HERE: http://www.cs.ubc.ca/~dmeyer/blockmason-wiov-final.pdf --Dutch _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefan de Konink
2008-Oct-31 03:50 UTC
Re: [Xen-devel] [Patch 2/3] New blktap implementation
Dutch Meyer wrote:> 1) A patch to add a new blktap implementation that is feature equivalent > to (or better than) the current *open source* blktap. This will eventually > replace the current blktap implementation.Is this blocktap2 less open source ;) Btw. Your Patch 1/3 never arrived at my inbox. Stefan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
It is exactly that. I definitely sent parts 0 an 1, but the department mailserver can be a little funny here sometimes. I''ll try to resend shortly. --Dutch On Fri, 31 Oct 2008, Stefan de Konink wrote:> Dutch Meyer wrote: >> 1) A patch to add a new blktap implementation that is feature equivalent >> to (or better than) the current *open source* blktap. This will >> eventually >> replace the current blktap implementation. > > Is this blocktap2 less open source ;) Btw. Your Patch 1/3 never arrived at my > inbox. > > > Stefan >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dutch Meyer schrieb:> Patch 2 of 3. > > Signed-off-by: Jake Wires <jake.wires@citrix.com>, Dutch Meyer > <dmeyer@cs.ubc.ca> > > This is a new and rewritten version of blktap that we have developed at > Citrix. The current version of blktap is left functionally unmodified. > The change set consists of three patches.You only have attached a fixqcow patch, no blktap rewrite. Could you explain what the qcow patch is supposed to fix? I think we need good reasons to change this code because every change increases the differences between the tapdisk and qemu implementation of the format. It was agreed that eventually we want to get rid of the tapdisk implementation of the formats qemu can provide, but in the meantime we should at least be careful not to increase differences. If these are real fixes, maybe they should also go into upstream qemu? Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Basically the qcow tools as they exist in the xen repo are broken. img2raw doesn''t zero its file descriptor, so polling on it can fail dramatically. Unless I''m horribly mistaken the driver routines that open a qcow image, in trying to modify the endian of the L1 table, completely clobber the file header. Likely this patch (or one like it) needs to be applied to the old blktap as well, insofar as it exists with this new blktap patch. --Dutch On Fri, 31 Oct 2008, Kevin Wolf wrote:> Dutch Meyer schrieb: >> Patch 2 of 3. >> >> Signed-off-by: Jake Wires <jake.wires@citrix.com>, Dutch Meyer >> <dmeyer@cs.ubc.ca> >> >> This is a new and rewritten version of blktap that we have developed at >> Citrix. The current version of blktap is left functionally unmodified. >> The change set consists of three patches. > > You only have attached a fixqcow patch, no blktap rewrite. > > Could you explain what the qcow patch is supposed to fix? I think we > need good reasons to change this code because every change increases the > differences between the tapdisk and qemu implementation of the format. > It was agreed that eventually we want to get rid of the tapdisk > implementation of the formats qemu can provide, but in the meantime we > should at least be careful not to increase differences. > > If these are real fixes, maybe they should also go into upstream qemu? > > Kevin > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel