[libvirt] [PATCH 0/2] Two simple sparse streams fixes

[Michal Privoznik]

On 05/31/2017 01:03 PM, Martin Kletzander wrote:
> On Tue, May 30, 2017 at 12:44:21PM +0200, Michal Privoznik wrote:
>> I've been experimenting with sparse streams and found a bug. If you
>> try to
>> download a volume which doesn't support sparseness here's what happens:
>>
>> # virsh vol-download --sparse
>> /dev/disk/by-path/ip-XX.XX.XX.XX:3260-iscsi-iqn.2017-03.com.blah:server-lun-0
>> /mnt/floppy/blah.raw
>>
>> # echo $?
>> 0
>> # ls -lhs /mnt/floppy/bla.raw
>> 0 -rw-r--r-- 1 root root 0 May 30 12:40 /mnt/floppy/bla.raw
>>
>> That's not good. iSCSI doesn't know anything about sparseness so an
>> error is
>> expected here. Fortunately, the fix is fairly simple:
>>
>> # virsh vol-download --sparse
>> /dev/disk/by-path/ip-XX.XX.XX.XX:3260-iscsi-iqn.2017-03.com.blah:server-lun-0
>> /mnt/floppy/bla.raw
>> error: cannot close volume
>> /dev/disk/by-path/ip-XX.XX.XX.XX:3260-iscsi-iqn.2017-03.com.blah:server-lun-0
>>
>> error: Unable to seek to data: Invalid argument
>>
> 
> I'm also getting confusing errors when there is no space on the
> destination:
>  error: cannot receive data from volume fedora.img
>  error: An error occurred, but the cause is unknown

I have a fix for this (will send shortly).

> 
> But that's not related to the sparse streams (unless it was caused by
> making the iohelper a thread).
> 
> ... few moments later after /me tries just a thing or two ...
> 
> Well, this made me try out few more things and I've found out few
> things.  I'm not sure what's related to your patches and what's not, so
> here's the rundown, and I'll let you decide:
> 
> - vol-download --sparse --offset $source_file_size --length 1
>   /path/to/source.file destination.file
> 
>    - Every now and then (not always) it gets stuck waiting for the
>      daemon to receive data (see backtrace below), but the daemon is not
>      waiting for anything, it's just some weird race.  We can try
>      debugging it with wireshark later.  That file ends with a hole.

But I do not have a fix for this one. Frankly, I have no idea what is
going on. Looks to me like:

a) the daemon reaches the end of the stream, but doesn't call
virStreamFinish
b) client reads all the incoming data from the stream, and after that
finds incoming queue empty so it sends "gimme more data" packet to the
daemon
c) the I/O thread in the daemon has died already (it had read everything
it was supposed to), so it closes the write end of the pipe

d) the read end of the pipe is not added to the event loop since we are
not expecting more data in the stream

Frankly, I have no idea what is really going on or how to fix it. So if
somebody else can take a look I'd appreciate it.

Michal