From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/8] block: add image streaming block job
Date: Wed, 02 Nov 2011 17:43:46 +0100 [thread overview]
Message-ID: <4EB17342.4050008@redhat.com> (raw)
In-Reply-To: <CAJSP0QXFrJiq8OhHAZRKW63X4BapnLcQ-DwQjEHH6n8J3KD4Ag@mail.gmail.com>
Am 02.11.2011 16:43, schrieb Stefan Hajnoczi:
> On Tue, Nov 1, 2011 at 6:06 PM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
>> On Thu, Oct 27, 2011 at 04:22:50PM +0100, Stefan Hajnoczi wrote:
>>> +static int stream_one_iteration(StreamBlockJob *s, int64_t sector_num,
>>> + void *buf, int max_sectors, int *n)
>>> +{
>>> + BlockDriverState *bs = s->common.bs;
>>> + int ret;
>>> +
>>> + trace_stream_one_iteration(s, sector_num, max_sectors);
>>> +
>>> + ret = bdrv_is_allocated(bs, sector_num, max_sectors, n);
>>> + if (ret < 0) {
>>> + return ret;
>>> + }
>>
>> bdrv_is_allocated is still synchronous? If so, there should be at least
>> a plan to make it asynchronous.
>
> Yes, that's a good discussion to have. My thoughts are that
> bdrv_is_allocated() should be executed in coroutine context.
bdrv_is_allocated() isn't coroutine-safe. You need to introduce
bdrv_co_is_allocated and convert all drivers before you can do this. You
don't want to access the qcow2 metadata cache without holding the lock,
for example.
> The
> semantics are a little tricky because of parallel requests:
>
> 1. If a write request is in progress when we do bdrv_is_allocated() we
> might get back "unallocated" even though clusters are just being
> allocated.
> 2. If a TRIM request is in progress when we do bdrv_is_allocated() we
> might get back "allocated" even though clusters are just being
> deallocated.
>
> In order to be reliable the caller needs to be aware of parallel
> requests. I think it's correct to defer this problem to the caller.
I agree.
> In the case of image streaming we're not TRIM-safe, I haven't really
> thought about it yet. But we are safe against parallel write requests
> because there is serialization to prevent copy-on-read requests from
> racing with write requests.
I don't think it matters. If you lose a bdrv_discard, nothing bad has
happened. bdrv_discard means that you have undefined content afterwards.
Kevin
next prev parent reply other threads:[~2011-11-02 16:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-27 15:22 [Qemu-devel] [PATCH 0/8] block: generic image streaming Stefan Hajnoczi
2011-10-27 15:22 ` [Qemu-devel] [PATCH 1/8] coroutine: add co_sleep_ns() coroutine sleep function Stefan Hajnoczi
2011-10-27 15:22 ` [Qemu-devel] [PATCH 2/8] block: add BlockJob interface for long-running operations Stefan Hajnoczi
2011-10-27 15:22 ` [Qemu-devel] [PATCH 3/8] block: add image streaming block job Stefan Hajnoczi
2011-11-01 18:06 ` Marcelo Tosatti
2011-11-02 15:43 ` Stefan Hajnoczi
2011-11-02 16:43 ` Kevin Wolf [this message]
2011-11-03 16:34 ` Marcelo Tosatti
2011-11-04 8:03 ` Stefan Hajnoczi
2011-10-27 15:22 ` [Qemu-devel] [PATCH 4/8] qmp: add block_stream command Stefan Hajnoczi
2011-10-27 15:22 ` [Qemu-devel] [PATCH 5/8] qmp: add block_job_set_speed command Stefan Hajnoczi
2011-10-27 15:22 ` [Qemu-devel] [PATCH 6/8] qmp: add block_job_cancel command Stefan Hajnoczi
2011-10-27 15:22 ` [Qemu-devel] [PATCH 7/8] qmp: add query-block-jobs Stefan Hajnoczi
2011-10-27 15:22 ` [Qemu-devel] [PATCH 8/8] test: add image streaming test cases Stefan Hajnoczi
2011-10-27 18:58 ` [Qemu-devel] [PATCH 0/8] block: generic image streaming Luiz Capitulino
2011-11-01 16:46 ` Marcelo Tosatti
2011-11-02 11:06 ` Stefan Hajnoczi
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=4EB17342.4050008@redhat.com \
--to=kwolf@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@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).