Re: [Qemu-devel] active block commit bug?

[Jeff Cody]

On Wed, Jun 04, 2014 at 04:55:04PM -0600, Eric Blake wrote:
> Testing on Fedora 20 (JSON output slightly modified for legibility):
> 
> $ qemu-kvm --version
> QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard
> $ touch f
> $ qemu-kvm -qmp stdio -drive file=f
>  <= {"QMP": {"version": {"qemu": {"micro": 0, "minor": 0, "major": 2},
> "package": ""}, "capabilities": []}}
> 
> {"execute":"qmp_capabilities"}
>  <= {"return": {}}
> 
> {"execute":"blockdev-snapshot-sync","arguments":{"device":"ide0-hd0","snapshot-file":"g"}}
> Formatting 'g', fmt=qcow2 size=0 backing_file='f' backing_fmt='raw'
> encryption=off cluster_size=65536 lazy_refcounts=off
>  <= {"return": {}}
> 
> {"execute":"block-commit","arguments":{"device":"ide0-hd0","top":"g"}}
> {"timestamp": {"seconds": 1401921011, "microseconds": 498888}, "event":
> "BLOCK_JOB_COMPLETED", "data": {"device": "ide0-hd0", "len": 0,
> "offset": 0, "speed": 0, "type": "commit"}}
>  <= {"return": {}}
> 
> {"execute":"query-block-jobs"}
>  <= {"return": []}
> 
> Huh? I thought that an active commit was not supposed to complete
> automatically, but that the job would remain around until I either
> 'block-job-cancel' or 'block-job-complete' it.  That is, I should have
> gotten a BLOCK_JOB_READY event and still see the job when I query for
> it.  Where am I going wrong, or did I uncover a bug in active commit?
>

I tried repeating your findings, but I couldn't, until I noticed that
'f' was just a 0-length raw image in your test.

The snapshot file will be the same size, 0.  So when we go to perform
the active commit, we short-circuit at the beginning, since we are
committing a zero-length image:

from block/mirror.c (active commit is a special mirror case):

 static void coroutine_fn mirror_run(void *opaque)
 {
     MirrorBlockJob *s = opaque;
     BlockDriverState *bs = s->common.bs;
     int64_t sector_num, end, sectors_per_chunk, length;
     uint64_t last_pause_ns;
     BlockDriverInfo bdi;
     char backing_filename[1024];
     int ret = 0;
     int n;
 
     if (block_job_is_cancelled(&s->common)) {
         goto immediate_exit;
     }
 
     s->common.len = bdrv_getlength(bs);
     if (s->common.len <= 0) {
         block_job_completed(&s->common, s->common.len);
         return;
     }
     ^^^^^
     we exit early here, with a completed message, since there is
     nothing to do.

If 'g' had increased to non-zero size, then you would have received a
BLOCK_JOB_READY instead.


-Jeff