From: Alex Elder <elder@ieee.org>
To: Ilya Dryomov <idryomov@redhat.com>, ceph-devel@vger.kernel.org
Cc: Alex Elder <elder@linaro.org>
Subject: Re: [PATCH 3/3] rbd: do not treat standalone as flatten
Date: Mon, 26 Jan 2015 21:55:19 -0600 [thread overview]
Message-ID: <54C70C27.6000301@ieee.org> (raw)
In-Reply-To: <1421757669-38796-4-git-send-email-idryomov@redhat.com>
On 01/20/2015 06:41 AM, Ilya Dryomov wrote:
> If the clone is resized down to 0, it becomes standalone. If such
> resize is carried over while an image is mapped we would detect this
> and call rbd_dev_parent_put() which means "let go of all parent state,
> including the spec(s) of parent images(s)". This leads to a mismatch
> between "rbd info" and sysfs parent fields, so a fix is in order.
>
> # rbd create --image-format 2 --size 1 foo
> # rbd snap create foo@snap
> # rbd snap protect foo@snap
> # rbd clone foo@snap bar
> # DEV=$(rbd map bar)
> # rbd resize --allow-shrink --size 0 bar
> # rbd resize --size 1 bar
> # rbd info bar | grep parent
> parent: rbd/foo@snap
>
> Before:
>
> # cat /sys/bus/rbd/devices/0/parent
> (no parent image)
>
> After:
>
> # cat /sys/bus/rbd/devices/0/parent
> pool_id 0
> pool_name rbd
> image_id 10056b8b4567
> image_name foo
> snap_id 2
> snap_name snap
> overlap 0
>
> Signed-off-by: Ilya Dryomov <idryomov@redhat.com>
Hmm. Interesting.
I think that a parent with an overlap of 0 is of no
real use. So in the last patch I was suggesting it
should just go away.
But now, looking at it from this perspective, the fact
that an image *came from* a particular parent, but which
has no more overlap, could be useful information. The
parent shouldn't simply go away without the user requesting
that.
I haven't completely followed through the logic of keeping
the reference around but I understand what you're doing and
it looks OK to me.
Reviewed-by: Alex Elder <elder@linaro.org>
> ---
> drivers/block/rbd.c | 30 ++++++++++--------------------
> 1 file changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
> index b85d52005a21..e818c2a6ffb1 100644
> --- a/drivers/block/rbd.c
> +++ b/drivers/block/rbd.c
> @@ -4273,32 +4273,22 @@ static int rbd_dev_v2_parent_info(struct rbd_device *rbd_dev)
> }
>
> /*
> - * We always update the parent overlap. If it's zero we
> - * treat it specially.
> + * We always update the parent overlap. If it's zero we issue
> + * a warning, as we will proceed as if there was no parent.
> */
> - rbd_dev->parent_overlap = overlap;
> if (!overlap) {
> -
> - /* A null parent_spec indicates it's the initial probe */
> -
> if (parent_spec) {
> - /*
> - * The overlap has become zero, so the clone
> - * must have been resized down to 0 at some
> - * point. Treat this the same as a flatten.
> - */
> - rbd_dev_parent_put(rbd_dev);
> - pr_info("%s: clone image now standalone\n",
> - rbd_dev->disk->disk_name);
> + /* refresh, careful to warn just once */
> + if (rbd_dev->parent_overlap)
> + rbd_warn(rbd_dev,
> + "clone now standalone (overlap became 0)");
> } else {
> - /*
> - * For the initial probe, if we find the
> - * overlap is zero we just pretend there was
> - * no parent image.
> - */
> - rbd_warn(rbd_dev, "ignoring parent with overlap 0");
> + /* initial probe */
> + rbd_warn(rbd_dev, "clone is standalone (overlap 0)");
> }
> }
> + rbd_dev->parent_overlap = overlap;
> +
> out:
> ret = 0;
> out_err:
>
prev parent reply other threads:[~2015-01-27 3:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 12:41 [PATCH 0/3] rbd: parent_overlap == 0 fixes Ilya Dryomov
2015-01-20 12:41 ` [PATCH 1/3] rbd: fix rbd_dev_parent_get() when parent_overlap == 0 Ilya Dryomov
2015-01-21 1:22 ` Josh Durgin
2015-01-27 3:14 ` Alex Elder
2015-01-20 12:41 ` [PATCH 2/3] rbd: drop parent_ref in rbd_dev_unprobe() unconditionally Ilya Dryomov
2015-01-21 1:24 ` Josh Durgin
2015-01-27 3:40 ` Alex Elder
2015-01-20 12:41 ` [PATCH 3/3] rbd: do not treat standalone as flatten Ilya Dryomov
2015-01-21 1:25 ` Josh Durgin
2015-01-27 3:55 ` Alex Elder [this message]
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=54C70C27.6000301@ieee.org \
--to=elder@ieee.org \
--cc=ceph-devel@vger.kernel.org \
--cc=elder@linaro.org \
--cc=idryomov@redhat.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.