在 2018/4/4 23:01, Stefan Hajnoczi 写道:
> Commit 4486e89c219c0d1b9bd8dfa0b1dd5b0d51ff2268 ("vl: introduce
> vm_shutdown()") added a bdrv_drain_all() call. As a side-effect of the
> drain operation the block job iterates one more time than before. The
> 185 output no longer matches and the test
$ gdb -p 13024 -batch -ex "thread apply all bt"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x7f98275cfaff in ppoll () from /lib64/libc.so.6
Thread 1 (Thread 0x7f983e30ab00 (LWP 13024)):
#0 0x7f98275cfaff in ppoll () from
On Sun, Apr 8, 2018 at 9:27 PM Benny Zlotnik wrote:
> Hi,
>
> As part of copy operation initiated by rhev got stuck for more than a day
> and consumes plenty of CPU
> vdsm 13024 3117 99 Apr07 ?1-06:58:43 /usr/bin/qemu-img convert
> -p -t none -T none -f qcow2
>
On Fri, 04/06 13:41, Paolo Bonzini wrote:
> On 05/04/2018 14:55, Stefan Hajnoczi wrote:
> > bdrv_copy_file_range() will invoke bdrv_co_copy_file_range_src() on
> > src[qcow2]. The qcow2 block driver will invoke
> > bdrv_co_copy_file_range_src() on src[file]. The file-posix driver will
> > invoke