All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: jcody@redhat.com
Cc: supriyak@linux.vnet.ibm.com, pbonzini@redhat.com,
	eblake@redhat.com, qemu-devel@nongnu.org, stefanha@gmail.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 12:19:00 +0200	[thread overview]
Message-ID: <5049CA14.9050902@redhat.com> (raw)
In-Reply-To: <5048BA3C.5030701@redhat.com>

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?

Kevin

  reply	other threads:[~2012-09-07 10:19 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 [this message]
2012-09-07 15:17         ` Jeff Cody
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=5049CA14.9050902@redhat.com \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=jcody@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.