qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH for-2.10] quorum: Handle bdrv_getlength() failur


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH for-2.10] quorum: Handle bdrv_getlength() failures in quorum_co_flush()
Date: Mon, 7 Aug 2017 06:29:09 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]