On 04/17/2017 02:18 PM, John Snow wrote: >> @@ -346,13 +349,15 @@ static uint64_t coroutine_fn >> mirror_iteration(MirrorBlockJob *s) >> if (sector_num < 0) { >> bdrv_set_dirty_iter(s->dbi, 0); >> sector_num = bdrv_dirty_iter_next(s->dbi); >> - trace_mirror_restart_iter(s, bdrv_get_dirty_count(s->dirty_bitmap)); >> + trace_mirror_restart_iter(s, bdrv_get_dirty_count(s->dirty_bitmap) * >> + BDRV_SECTOR_SIZE); > > mirror_restart_iter(void *s, int64_t cnt) "s %p dirty count %"PRId64 > > I guess the print doesn't really bother to say what the unit is, just a > "dirty count." > > Does this conflict with the bitmap series, though? (Won't need to scale > by BDRV_SECTOR_SIZE after that, I think.) >
That series depends on this one going in first (as currently written), and indeed, in that series, the code DOES simplify to drop the '* BDRV_SECTOR_SIZE' in the patch that changes the return scale of bdrv_get_dirty_count(). >> backup_do_cow_skip(void *job, int64_t start) "job %p start %"PRId64 >> backup_do_cow_process(void *job, int64_t start) "job %p start %"PRId64 >> backup_do_cow_read_fail(void *job, int64_t start, int ret) "job %p start >> %"PRId64" ret %d" > > I guess these three were "cluster" based, but you didn't need to change > anything to assert them as byte-based. > >> > > Under the assumption that it's okay to change tracing output without > being able to differentiate between new and old output: I'll leave that to Stefan's discretion as trace maintainer, but my thoughts are that tracing is for debugging purposes, and as long as you know what binary you are debugging, you can figure out what the trace message meant by referring back to the source that generated that binary. > > Reviewed-by: John Snow <js...@redhat.com> > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature