qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 14/19] block: vmdk image file reopen


From: Jeff Cody
Subject: Re: [Qemu-devel] [PATCH v3 14/19] block: vmdk image file reopen
Date: Thu, 20 Sep 2012 10:49:01 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0

On 09/20/2012 10:12 AM, Kevin Wolf wrote:
> Am 18.09.2012 20:53, schrieb Jeff Cody:
>> This patch supports reopen for VMDK image files.  VMDK extents are added
>> to the existing reopen queue, so that the transactional model of reopen
>> is maintained with multiple image files.
>>
>> Signed-off-by: Jeff Cody <address@hidden>
>> ---
>>  block/vmdk.c | 35 +++++++++++++++++++++++++++++++++++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/block/vmdk.c b/block/vmdk.c
>> index bba4c61..f2e861b 100644
>> --- a/block/vmdk.c
>> +++ b/block/vmdk.c
>> @@ -300,6 +300,40 @@ static int vmdk_is_cid_valid(BlockDriverState *bs)
>>      return 1;
>>  }
>>  
>> +/* Queue extents, if any, for reopen() */
>> +static int vmdk_reopen_prepare(BDRVReopenState *state,
>> +                               BlockReopenQueue *queue, Error **errp)
>> +{
>> +    BDRVVmdkState *s;
>> +    int ret = -1;
>> +    int i;
>> +    VmdkExtent *e;
>> +
>> +    assert(state != NULL);
>> +    assert(state->bs != NULL);
>> +
>> +    if (queue == NULL) {
>> +        error_set(errp, ERROR_CLASS_GENERIC_ERROR,
>> +                 "No reopen queue for VMDK extents");
>> +        goto exit;
>> +    }
>> +
>> +    s = state->bs->opaque;
>> +
>> +    assert(s != NULL);
>> +
>> +    for (i = 0; i < s->num_extents; i++) {
>> +        e = &s->extents[i];
>> +        if (e->file != state->bs->file) {
>> +            bdrv_reopen_queue(queue, e->file, state->flags);
> 
> This is wrong, you can't abort the transaction if you do it like this.
> 
> VMDK needs to separately pass through each of prepare/commit/abort to
> all extents, it can't use the all-in-one function.
> 
> Kevin
> 
(Follow up from conversation on IRC)

This is actually correct, because it is adding the extents to the queue
in the prepare(). This will cause the extents to go through the same
transactional prepare/commit/abort cycle as the rest of the images in
the queue.

Jeff



reply via email to

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