qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).