Re: [Xen-devel] Basic blktap2 functionality issues.

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 29 Mar 2012, greg@xxxxxxxxxxxx wrote:
> Hi, hope the day is going well for everyone.
> 
> I had posted a note about this issue two weeks ago and didn't get any
> response.  I don't know if that indicates that people are not using
> blktap or if the question stumped everyone.
> 
> First of all there is a documentable issue with blktap in 4.1.2 and
> xl.  Anyone trying to use it to export files to a guest will be
> affected.  Using xl to do 'block-attach' and 'block-detach' in dom0
> also doesn't work in stock 4.1.2 so I suspect there are generic issues
> with blktap and xl.
> 
> In stock 4.1.2 using xl results in the tapdisk2 server process being
> orphaned.  There is a patch floating around from Ian Campbell which
> fixes this problem and either creates or uncovers what may be a more
> fundamental problem.
> 
> With Ian's patch applied the tapdisk2 process terminates but the
> tapdisk device is not released resulting in a steady accumulation of
> orphan minor numbers.  The underlying cause of this appears to be a
> resource deadlock between xl requesting a detach of the VBD and the
> tapdisk2 process.
> 
> Ian actually acknowledges the phenomenon in one of his posts saying
> there appeared to be a 'hang' when the VBD is released with his
> patches.  The 'hang' is actually a livelock where the entire kernel
> blocks until the select call from xl to the tapdisk2 process times out
> and rescues things.  The error return from the select call is what
> causes the xl code to not complete the release of the tapdisk minor.
> 
> I'm still hunting through the code maze trying to find the underlying
> problem.  The tapdisk2 process is hanging on the munmap of the ring
> buffers.  It 'feels' as if the problem may be secondary to xl still
> holding a reference to some resource which blocks the unmap of the
> ring buffers.
> 
> I will continue to hunt but if anyone has any pointers send them my
> way.  It takes a bit of time to come up to speed on all the code
> paths.
> 
> In a broader context I think the XEN community needs to take a
> reasoned look at how to handle the file issue.  It appears as if Dan
> Stodden has disappeared so I get the sense the entire blktap2
> architecture is a bit rudderless (no judgement just observation).  I'm
> trying to put my money where my mouth is and actually hunt for the
> problems which are there.
> 
> I've seen rumbles on LKML about discussions with regards to
> modifications to loop in order to deal with the page cache issues
> which hinder the reliability of delivering virtual block devices over
> loop.  I don't know how far out that is or even if it will eventuate.
> I've also heard rumbles about a mythical 'blktap3' which runs
> completely in userspace.  If that is the direction things are going I
> would certainly be willing to hammer on that rather then put more time
> into blktap2 if there is 'blktap3' code someplace.
> 
> I will look forward to any comments or suggestions people may have.

A completely userspace blktap version is indeed in the work, but it is
not clear yet when it is going to be ready.

Alternatively if you don't need VHD format support, you can use QCOW or
QCOW2 with upstream QEMU in xen-unstable, that leads to very good
performances and still provides copy on write support.

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