All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
To: Alberto Garcia <berto@igalia.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	"jcody@redhat.com" <jcody@redhat.com>,
	"mreitz@redhat.com" <mreitz@redhat.com>,
	Denis Lunev <den@virtuozzo.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH RFC 1/1] Stream block job involves copy-on-read filter
Date: Mon, 11 Feb 2019 14:54:55 +0000	[thread overview]
Message-ID: <96affe90-df67-41d7-e681-7c370a8513e0@virtuozzo.com> (raw)
In-Reply-To: <w51sgwuv2ok.fsf@maestria.local.igalia.com>



On 11/02/2019 17:07, Alberto Garcia wrote:
> On Fri 08 Feb 2019 04:29:48 PM CET, Andrey Shinkevich wrote:
>> On 08/02/2019 16:13, Alberto Garcia wrote:
>>> On Wed 23 Jan 2019 12:54:24 PM CET, Andrey Shinkevich wrote:
>>>> +static BlockDriverState *insert_filter(BlockDriverState *bs, Error **errp)
>>>> +{
>>>> +    BlockDriverState *cor_filter_bs;
>>>> +    Error *local_err = NULL;
>>>> +
>>>> +    cor_filter_bs = create_filter_node(bs, errp);
>>>> +    if (cor_filter_bs == NULL) {
>>>> +        error_prepend(errp, "Could not create filter node: ");
>>>> +        return NULL;
>>>> +    }
>>>> +
>>>> +    bdrv_set_aio_context(cor_filter_bs, bdrv_get_aio_context(bs));
>>>> +
>>>> +    bdrv_drained_begin(bs);
>>>> +    bdrv_replace_node(bs, cor_filter_bs, &local_err);
>>>> +    bdrv_drained_end(bs);
>>>
>>> I think this was already discussed in the previous version of this
>>> patch: if you insert a copy-on-read filter here then all guest reads
>>> will copy the data from the backing chain, but you don't want to copy
>>> anything below the 'base' node, so the copy-on-read filter needs a
>>> 'base' parameter.
>>>
>> Before that, we still have the unresolved issue with getting the
>> filter as the 'base' input parameter. That happens sometimes because
>> the base is being searched by the file name, which is the same to the
>> one of the filter, rather than by the node name (!)
> 
> I'm not sure if I understand. block-stream has 'base' and 'base-node'
> parameters, and in the first case you would convert the file name to a
> node name.
> 
> stream_start() gets the BlockDriverState, not the file name, so why
> can't you get the node name from there and pass it to the copy-on-read
> filter?
> 
> Berto
> 
When the block-stream QMP command is run with a base file path name,
qmp_block_stream() invokes bdrv_lookup_bs() to get the
BlockDriverState by the file name and to pass it further to
stream_start(), while has_base_node == false.
It works the same way for the copy-on-read filter inserted above the
QCOW2 node because they both have the same and only file path name.
So, the BlockDriverState of the filter is passed to the
stream_start() as the parameter instead of the one of the QCOW2 base
node. I emailed the workaround patch that skips the filter BS passed
to the stream_start() as the parameter, if any.
There is an idea of Vladimir to pass an intermediate node that has
the base node as its backing one instead. If you can suggest another
idea, it will be appreciated.

-- 
With the best regards,
Andrey Shinkevich

      parent reply	other threads:[~2019-02-11 14:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-23 11:54 [Qemu-devel] [PATCH RFC 1/1] Stream block job involves copy-on-read filter Andrey Shinkevich
2019-01-23 13:10 ` Vladimir Sementsov-Ogievskiy
2019-01-31 14:02 ` Andrey Shinkevich
2019-02-08 13:13 ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2019-02-08 15:29   ` Andrey Shinkevich
2019-02-11 14:07     ` Alberto Garcia
2019-02-11 14:51       ` Vladimir Sementsov-Ogievskiy
2019-02-11 15:52         ` Alberto Garcia
2019-02-11 16:58           ` Vladimir Sementsov-Ogievskiy
2019-02-12 11:35             ` Alberto Garcia
2019-02-14 13:43               ` Andrey Shinkevich
2019-02-18 10:08                 ` Vladimir Sementsov-Ogievskiy
2019-02-20  9:10                   ` Andrey Shinkevich
2019-02-11 14:54       ` Andrey Shinkevich [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=96affe90-df67-41d7-e681-7c370a8513e0@virtuozzo.com \
    --to=andrey.shinkevich@virtuozzo.com \
    --cc=berto@igalia.com \
    --cc=den@virtuozzo.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.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.