qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Xie Changlong <xiechanglong.d@gmail.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	Wen Congyang <wencongyang2@huawei.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	John Snow <jsnow@redhat.com>, qemu-devel <qemu-devel@nongnu.org>,
	qemu block <qemu-block@nongnu.org>,
	Zhang Chen <zhangchen.fnst@cn.fujitsu.com>,
	Zhang Hailiang <zhang.zhanghailiang@huawei.com>,
	Li Zhijian <lizhijian@cn.fujitsu.com>
Subject: Re: [Qemu-devel] block replication
Date: Fri, 11 Aug 2017 09:51:40 +0800	[thread overview]
Message-ID: <68203d39-2da3-037c-1ee9-9e3a2a3f064c@gmail.com> (raw)
In-Reply-To: <0731e80d-6a92-b1e8-d6b4-31cdb19f7cb3@virtuozzo.com>

在 8/10/2017 8:26 PM, Vladimir Sementsov-Ogievskiy 写道:
> 09.08.2017 17:11, Vladimir Sementsov-Ogievskiy wrote:
>> Hi Wen!
>>
>> I'm trying to understand block/replication code and have a question.
>>
>> Why should we block the region from intersecting cow requests when 
>> read? If I understand correctly
>>
>> regardless of writes to the secondary-disk we have consistent view of 
>> it through hidden-disk:
>>
>> Even if we are intersecting with some writes to secondary-disk (and 
>> corresponding cow-requests), the
>>
>> data in secondary disk will not be updated until backed up to 
>> hidden-disk, therefore, for read we have two
>>
>> options:
>>
>> 1. read old data from secondary-disk (unallocated region in 
>> hidden-disk means data in secondary-disk is not updated yet)
>>
>> 2. read backed-up data from hidden-disk (data in secondary-disk may be 
>> already updated but we don't care)
>>
>> (the whole region to read may consists of parts, corresponding to 1 or 
>> 2, but this should be ok too)
>>
>> Where am I wrong?
> 
> Ok, now I think this is needed to prevent intersecting of writes and 
> reads on hidden-disk. If it so, I think it is better to use serializing 

Hi, Vladimir. Pls refer 
https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg03025.html

BTW, wen's email has changed, also CC Zhang Hailiang, Zhang Chen, Li Zhijian

> requests
> mechanism (just serialize all requests on hidden-disk, and on write wait 
> for all intersecting serializing requests, on read wait for intersecting 
> serializing writes) - it may require additional
> option for BlockDriverState, but it is more generic and more clear than 
> export internal backup things to lock disk region. This also can be 
> reused for image-fleecing scheme
> (which is based on same pattern  [active-disk is backing for temp-disk, 
> backup sync=none from active to temp, read from temp])
> 
>>
>>
>> ======
>>
>> static coroutine_fn int replication_co_readv(BlockDriverState *bs,
>>                                              int64_t sector_num,
>>                                              int remaining_sectors,
>>                                              QEMUIOVector *qiov)
>> {
>>     BDRVReplicationState *s = bs->opaque;
>>     BdrvChild *child = s->secondary_disk;
>>     BlockJob *job = NULL;
>>     CowRequest req;
>>     int ret;
>>
>>     if (s->mode == REPLICATION_MODE_PRIMARY) {
>>         /* We only use it to forward primary write requests */
>>         return -EIO;
>> }
>>
>>     ret = replication_get_io_status(s);
>>     if (ret < 0) {
>>         return ret;
>> }
>>
>>     if (child && child->bs) {
>>         job = child->bs->job;
>> }
>>
>>     if (job) {
>>         uint64_t remaining_bytes = remaining_sectors * BDRV_SECTOR_SIZE;
>>
>> backup_wait_for_overlapping_requests(child->bs->job,
>>                                              sector_num * 
>> BDRV_SECTOR_SIZE,
>> remaining_bytes);
>>         backup_cow_request_begin(&req, child->bs->job,
>>                                  sector_num * BDRV_SECTOR_SIZE,
>> remaining_bytes);
>>         ret = bdrv_co_readv(bs->file, sector_num, remaining_sectors,
>> qiov);
>> backup_cow_request_end(&req);
>>         goto out;
>> }
>>
>>     ret = bdrv_co_readv(bs->file, sector_num, remaining_sectors, qiov);
>> out:
>>     return replication_return_value(s, ret);
>> }
>>
> 

-- 
Thanks
     -Xie

      reply	other threads:[~2017-08-11  1:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-09 14:11 [Qemu-devel] block replication Vladimir Sementsov-Ogievskiy
2017-08-10 12:26 ` Vladimir Sementsov-Ogievskiy
2017-08-11  1:51   ` Xie Changlong [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=68203d39-2da3-037c-1ee9-9e3a2a3f064c@gmail.com \
    --to=xiechanglong.d@gmail.com \
    --cc=jsnow@redhat.com \
    --cc=lizhijian@cn.fujitsu.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.com \
    --cc=wencongyang2@huawei.com \
    --cc=zhang.zhanghailiang@huawei.com \
    --cc=zhangchen.fnst@cn.fujitsu.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).