[libvirt] [PATCH 0/2] Two simple sparse streams fixes
Michal Privoznik
mprivozn at redhat.com
Wed May 31 11:17:13 UTC 2017
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
Looks like one of the callbacks is not reporting errors.
>
> 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.
>
> Thread 1 (Thread 0x7f1d2b434880 (LWP 28584)):
> #0 0x00007f1d2796efbd in poll () at ../sysdeps/unix/syscall-template.S:84
> #1 0x00007f1d2a806ee3 in poll (__timeout=5000, __nfds=2,
> __fds=0x7ffe9effd640) at /usr/include/bits/poll2.h:46
> #2 virNetClientIOEventLoop (client=client at entry=0x563525bb06d0,
> thiscall=thiscall at entry=0x563525badc00) at rpc/virnetclient.c:1664
> #3 0x00007f1d2a8074d3 in virNetClientIO
> (client=client at entry=0x563525bb06d0, thiscall=0x563525badc00) at
> rpc/virnetclient.c:1957
> #4 0x00007f1d2a80780e in virNetClientSendInternal
> (client=client at entry=0x563525bb06d0, msg=msg at entry=0x563525bb03d0,
> expectReply=expectReply at entry=true, nonBlock=nonBlock at entry=false) at
> rpc/virnetclient.c:2132
> #5 0x00007f1d2a808dfc in virNetClientSendWithReplyStream
> (client=client at entry=0x563525bb06d0, msg=msg at entry=0x563525bb03d0,
> st=st at entry=0x563525bade10) at rpc/virnetclient.c:2236
> #6 0x00007f1d2a80ab2d in virNetClientStreamRecvPacket
> (st=st at entry=0x563525bade10, client=0x563525bb06d0,
> data=data at entry=0x7f1d20686010 "", nbytes=nbytes at entry=262120,
> nonblock=false, flags=32766, flags at entry=1) at rpc/virnetclientstream.c:499
> #7 0x00007f1d2a7e0e3e in remoteStreamRecvFlags (st=0x563525badc60,
> data=0x7f1d20686010 "", nbytes=262120, flags=1) at
> remote/remote_driver.c:5664
> #8 0x00007f1d2a7c8347 in virStreamRecvFlags
> (stream=stream at entry=0x563525badc60, data=0x7f1d20686010 "",
> nbytes=nbytes at entry=262120, flags=flags at entry=1) at libvirt-stream.c:361
> #9 0x00007f1d2a7c9b7f in virStreamSparseRecvAll
> (stream=stream at entry=0x563525badc60, handler=0x563525760196
> <virshStreamSink>, holeHandler=0x56352576020b <virshStreamSkip>,
> opaque=opaque at entry=0x7ffe9effd954) at libvirt-stream.c:964
> #10 0x000056352576232e in cmdVolDownload (ctl=0x7ffe9effda40,
> cmd=<optimized out>) at virsh-volume.c:834
> #11 0x00005635257662f1 in vshCommandRun (ctl=0x7ffe9effda40,
> cmd=0x563525bacf40) at vsh.c:1327
> #12 0x000056352572aee2 in main (argc=9, argv=<optimized out>) at
> virsh.c:929
>
> Trying to reproduce yet another one, the command gets stuck even with
> different offsets.
>
> - vol-download --sparse --offset $X --length 1
> /path/to/source.file destination.file
>
> - This does not respect the length if:
> X > $source_file_size - $last_hole_size
>
> The size ends up being $source_file_size - $X
>
Okay, I'll look into these. Thanks.
>
>
> I'm afraid to try more things, but I can provide more info for these if
> you want.
Don't be! At least somebody is testing the feature. Thanks.
Anyway, I'll send v2 on 1/2.
Michal
More information about the libvir-list
mailing list