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

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

 



On Wednesday, 31 May 2017 13:03:38 CEST Martin Kletzander wrote:
>  - 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

Humble suggestion here: what about turning the simple scenarios above
as proper tests?

-- 
Pino Toscano

Attachment: signature.asc
Description: This is a digitally signed message part.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux