qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Cody <jcody@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: stefanha@gmail.com, supriyak@linux.vnet.ibm.com,
	eblake@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC v2 PATCH 1/6] block: add support functions for live commit, to find and delete images.
Date: Fri, 07 Sep 2012 11:17:29 -0400	[thread overview]
Message-ID: <504A1009.5030508@redhat.com> (raw)
In-Reply-To: <5049CA14.9050902@redhat.com>

On 09/07/2012 06:19 AM, Kevin Wolf wrote:
> Am 06.09.2012 16:59, schrieb Jeff Cody:
>> On 09/06/2012 09:23 AM, Kevin Wolf wrote:
>>> Am 30.08.2012 20:47, schrieb Jeff Cody:
>>>> Add bdrv_find_child(), and bdrv_delete_intermediate().
>>>>
>>>> bdrv_find_child():  given 'bs' and the active (topmost) BDS of an image chain,
>>>>                     find the image that is the immediate top of 'bs'
>>>>
>>>> bdrv_delete_intermediate():
>>>>                     Given 3 BDS (active, top, base), delete images above
>>>>                     base up to and including top, and set base to be the
>>>>                     parent of top's child node.
>>>>
>>>>                     E.g., this converts:
>>>>
>>>>                     bottom <- base <- intermediate <- top <- active
>>>>
>>>>                     to
>>>>
>>>>                     bottom <- base <- active
>>>>
>>>>                     where top == active is permitted, although active
>>>>                     will not be deleted.
>>>>
>>>> Signed-off-by: Jeff Cody <jcody@redhat.com>
>>>
>>> At first, when just reading the function name, I thought this would
>>> actually delete the image file. Of course, it only removes it from the
>>> backing file chain, but leaves the image file around. I don't have a
>>> good suggestion, but if someone has a better name, I think we should
>>> change it.
>>
>> Hmm, the naming seems consistent with bdrv_delete(), which does not
>> actually delete the image files either (and, that is essentially what
>> this does... calls bdrv_delete(), on the intermediate images).
>>
>> However, here are some other name proposals:
>>
>>    *  bdrv_disconnect_intermediate()
>>    *  bdrv_drop_intermediate()
>>    *  bdrv_shorten_chain()
> 
> bdrv_drop_intermediate() sounds good to me.
> 
>>>
>>>> +
>>>> +typedef struct BlkIntermediateStates {
>>>> +    BlockDriverState *bs;
>>>> +    QSIMPLEQ_ENTRY(BlkIntermediateStates) entry;
>>>> +} BlkIntermediateStates;
>>>> +
>>>> +
>>>> +/* deletes images above 'base' up to and including 'top', and sets the image
>>>> + * above 'top' to have base as its backing file.
>>>> + *
>>>> + * E.g., this will convert the following chain:
>>>> + * bottom <- base <- intermediate <- top <- active
>>>> + *
>>>> + * to
>>>> + *
>>>> + * bottom <- base <- active
>>>> + *
>>>> + * It is allowed for bottom==base, in which case it converts:
>>>> + *
>>>> + * base <- intermediate <- top <- active
>>>> + *
>>>> + * to
>>>> + *
>>>> + * base <- active
>>>> + *
>>>> + * It is also allowed for top==active, except in that case active is not
>>>> + * deleted:
>>>
>>> Hm, makes the interface inconsistent. Shouldn't you be using top ==
>>> intermediate and it would work without any special casing?
>>>
>>
>> To remain consistent, maybe we should define it as an error if
>> top==active, and return error in that case?  The caller can be
>> responsible for checking for that - if the caller wants to merge down
>> the active layer, there are additional steps to be taken anyway.
> 
> Yes, why not.
> 
> And we can always revisit when implementing the additional functionality.
> 
>>>> +        /* we could not find the image above 'top', this is an error */
>>>> +        goto exit;
>>>> +    }
>>>> +
>>>> +    /* if the active and top image passed in are the same, then we
>>>> +     * can't delete the active, so we start one below
>>>> +     */
>>>> +    intermediate = (active == top) ? active->backing_hd : top;
>>>
>>> Aha. So intermediate is used to undo the special case. Now we're always
>>> on the last image to be deleted.
>>>
>>> This is equivalent to an unconditional new_top_bs->backing_hd.
> 
> How about changing this to use the simpler unconditional version?

Sure - since active == top is now an error, there is no reason for the
more complicated logic.  And at this point, the statement
(new_top_bs->backing_hd == top) should always be true.

> 
> Kevin
> 

  reply	other threads:[~2012-09-07 15:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-30 18:47 [Qemu-devel] [RFC v2 PATCH 0/6] Live block commit Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [RFC v2 PATCH 1/6] block: add support functions for live commit, to find and delete images Jeff Cody
2012-09-06 13:23   ` Kevin Wolf
2012-09-06 14:58     ` Eric Blake
2012-09-06 14:59     ` Jeff Cody
2012-09-07 10:19       ` Kevin Wolf
2012-09-07 15:17         ` Jeff Cody [this message]
2012-08-30 18:47 ` [Qemu-devel] [RFC v2 PATCH 2/6] block: add live block commit functionality Jeff Cody
2012-09-06 14:00   ` Kevin Wolf
2012-09-06 20:37     ` Jeff Cody
2012-09-06 21:16       ` Eric Blake
2012-09-07 15:56         ` Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [RFC v2 PATCH 3/6] blockdev: rename block_stream_cb to a generic block_job_cb Jeff Cody
2012-09-07 16:27   ` Paolo Bonzini
2012-09-07 17:04     ` Jeff Cody
2012-09-07 17:09       ` Paolo Bonzini
2012-08-30 18:47 ` [Qemu-devel] [RFC v2 PATCH 4/6] qerror: new error for live block commit, QERR_TOP_NOT_FOUND Jeff Cody
2012-08-30 22:55   ` Eric Blake
2012-08-31 14:42     ` Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [RFC v2 PATCH 5/6] block: helper function, to find the base image of a chain Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [RFC v2 PATCH 6/6] QAPI: add command for live block commit, 'block-commit' Jeff Cody
2012-08-30 23:06   ` Eric Blake
2012-08-31 14:42     ` Jeff Cody
2012-09-06 14:29   ` Kevin Wolf
2012-09-06 21:00     ` Jeff Cody
2012-08-30 21:31 ` [Qemu-devel] [RFC v2 PATCH 0/6] Live block commit Jeff Cody

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=504A1009.5030508@redhat.com \
    --to=jcody@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=supriyak@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).