[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 entry=0x563525bb06d0,
> thiscall=thiscall entry=0x563525badc00) at rpc/virnetclient.c:1664
> #3  0x00007f1d2a8074d3 in virNetClientIO
> (client=client entry=0x563525bb06d0, thiscall=0x563525badc00) at
> rpc/virnetclient.c:1957
> #4  0x00007f1d2a80780e in virNetClientSendInternal
> (client=client entry=0x563525bb06d0, msg=msg entry=0x563525bb03d0,
> expectReply=expectReply entry=true, nonBlock=nonBlock entry=false) at
> rpc/virnetclient.c:2132
> #5  0x00007f1d2a808dfc in virNetClientSendWithReplyStream
> (client=client entry=0x563525bb06d0, msg=msg entry=0x563525bb03d0,
> st=st entry=0x563525bade10) at rpc/virnetclient.c:2236
> #6  0x00007f1d2a80ab2d in virNetClientStreamRecvPacket
> (st=st entry=0x563525bade10, client=0x563525bb06d0,
> data=data entry=0x7f1d20686010 "", nbytes=nbytes entry=262120,
> nonblock=false, flags=32766, flags 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 entry=0x563525badc60, data=0x7f1d20686010 "",
> nbytes=nbytes entry=262120, flags=flags entry=1) at libvirt-stream.c:361
> #9  0x00007f1d2a7c9b7f in virStreamSparseRecvAll
> (stream=stream entry=0x563525badc60, handler=0x563525760196
> <virshStreamSink>, holeHandler=0x56352576020b <virshStreamSkip>,
> opaque=opaque 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]