On 08/07/2017 03:43 AM, Alberto Garcia wrote: > On Fri 04 Aug 2017 05:44:00 PM CEST, Eric Blake wrote: >>> --- a/block/quorum.c >>> +++ b/block/quorum.c >>> @@ -785,8 +785,9 @@ static coroutine_fn int >>> quorum_co_flush(BlockDriverState *bs) >>> for (i = 0; i < s->num_children; i++) { >>> result = bdrv_co_flush(s->children[i]->bs); >>> if (result) { >>> + int64_t length = bdrv_getlength(s->children[i]->bs); >>> quorum_report_bad(QUORUM_OP_TYPE_FLUSH, 0, >>> - bdrv_getlength(s->children[i]->bs), >>> + length > 0 ? length : 0, >> >> In the fallback case, is always picking 0 good enough? Then again, >> this is in the error path, so it is unlikely in practice, and I don't >> see any better way to handle it. > > I don't see any better way to handle it either, and I'm not sure that it > matters much: this is a flush error event, the 'sectors-count' field > doesn't even mean anything, but we have to put something there.
If that's the case, can we ALWAYS report 0, instead of usually the length and sometimes 0? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature