[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 3/3] block: allow BLOCK_IMAGE_CORRUPTED to have

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 3/3] block: allow BLOCK_IMAGE_CORRUPTED to have a node name
Date: Thu, 19 Mar 2015 17:14:24 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 03/19/2015 04:38 PM, Alberto Garcia wrote:

>> And for this particular event, which is not tied to block jobs but
>> to generic block operation, isn't it possible that we could be
>> reporting a corrupted backing chain where we have neither a device
>> name (it is not the active layer) nor a node name (if we don't add
>> Jeff's patch to auto-name all nodes)?  In such a case, I don't know
>> that we can do much better anyways.
> Yes, it is perfectly possible. I guess any software that wants to
> handle those scenarios probably wants to give names to all nodes.
> From the QEMU side, apart from giving automatic names to all nodes I
> don't see any other solution.

In the context of block commit, libvirt found that reporting device name
to the end user was nicer than file name (since there are two events
emitted - one when the active layer has become synced with the lower
layer, and therefore where the node associated with device is still
'top'; and the other when the active layer has pivoted to the base layer
and top is no longer valid, therefore where the node associated with
device is now 'base' - since the two events are related but have
different file [node] names, having the device name made life easier).
But note that we still haven't exposed 'node' information in any of the
BLOCK_JOB_ERROR), and it might still make sense to do so, even if
libvirt doesn't need to expose those node names on to the end user.

But this is a counter-example - knowing just the device name does NOT
tell you which node is corrupted, if there is any possibility of a
snapshot or active commit changing the active node associated with the
device.  That's because there might be a race between the event
announcing corruption and some other action modifying the chain, such
that the client's notion of the active element of the chain is different
from the active element at the time the event was reported.

So the more I think about it, the more I'd like for this event to output
both 'device' (mandatory, with an empty string if we can't easily tie
the BDS to a single device) and 'node' (where 'node' can be optional,
and omitted if the BDS does not have a node name [if we ever add
generated node names, then we could make 'node' mandatory at that time]).

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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