All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wen Congyang <wency@cn.fujitsu.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>,
	zhanghailiang <zhang.zhanghailiang@huawei.com>,
	qemu block <qemu-block@nongnu.org>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Dong Eddie <eddie.dong@intel.com>,
	qemu devel <qemu-devel@nongnu.org>,
	"Michael R. Hines" <mrhines@linux.vnet.ibm.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Gonglei <arei.gonglei@huawei.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [Patch v12 resend 08/10] Implement new driver for block replication
Date: Mon, 4 Jan 2016 13:50:40 +0800	[thread overview]
Message-ID: <568A0830.2020301@cn.fujitsu.com> (raw)
In-Reply-To: <20151223094759.GB11394@stefanha-x1.localdomain>

On 12/23/2015 05:47 PM, Stefan Hajnoczi wrote:
> On Wed, Dec 02, 2015 at 01:37:25PM +0800, Wen Congyang wrote:
>> +    /*
>> +     * Only write to active disk if the sectors have
>> +     * already been allocated in active disk/hidden disk.
>> +     */
>> +    qemu_iovec_init(&hd_qiov, qiov->niov);
>> +    while (remaining_sectors > 0) {
>> +        ret = bdrv_is_allocated_above(top, base, sector_num,
>> +                                      remaining_sectors, &n);
> 
> There is a race condition here since multiple I/O requests can be in
> flight at the same time.   If two requests touch the same cluster
> between top->base then the result of these checks could be unreliable.

I don't think so. When we come here, primary qemu is gone, and failover is
done. We only write to active disk if the sectors have already been allocated
in active disk/hidden disk before failover. So it two requests touch the same
cluster, it is OK, because the function bdrv_is_allocated_above()'s return
value is not changed.

> 
> The simple but slow solution is to use a CoMutex to serialize requests.
> 
>> +        if (ret < 0) {
>> +            return ret;
>> +        }
>> +
>> +        qemu_iovec_reset(&hd_qiov);
>> +        qemu_iovec_concat(&hd_qiov, qiov, bytes_done, n * 512);
>> +
>> +        target = ret ? top : base;
>> +        ret = bdrv_co_writev(target, sector_num, n, &hd_qiov);
>> +        if (ret < 0) {
>> +            return ret;
>> +        }
>> +
>> +        remaining_sectors -= n;
>> +        sector_num += n;
>> +        bytes_done += n * BDRV_SECTOR_SIZE;
>> +    }
> 
> I think this can be replaced with an active commit block job that copies
> data down from the hidden/active disk to the secondary disk.  It is okay
> to keep writing to the secondary disk while the block job is running and
> then switch over to the secondary disk once it completes.

Yes, active commit is another choice. IIRC, I don't use it because mirror job
has some problem. It is fixed now(see bdrv_drained_begin()/bdrv_drained_end()
in the mirror job).
We will use mirror job in the next version.

> 
>> +
>> +    return 0;
>> +}
>> +
>> +static coroutine_fn int replication_co_discard(BlockDriverState *bs,
>> +                                               int64_t sector_num,
>> +                                               int nb_sectors)
>> +{
>> +    BDRVReplicationState *s = bs->opaque;
>> +    int ret;
>> +
>> +    ret = replication_get_io_status(s);
>> +    if (ret < 0) {
>> +        return ret;
>> +    }
>> +
>> +    if (ret == 1) {
>> +        /* It is secondary qemu and we are after failover */
>> +        ret = bdrv_co_discard(s->secondary_disk, sector_num, nb_sectors);
> 
> What if the clusters are still allocated in the hidden/active disk?
> 

What does discard do? Drop the data that allocated in the disk?
If so, I think I make a misunderstand. I will fix it in the next version.

Thanks
Wen Congyang

  reply	other threads:[~2016-01-04  5:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02  5:31 [Qemu-devel] [Patch v12 resend 00/10] Block replication for continuous checkpoints Wen Congyang
2015-12-02  5:31 ` [Qemu-devel] [Patch v12 resend 01/10] unblock backup operations in backing file Wen Congyang
2015-12-02  5:31 ` [Qemu-devel] [Patch v12 resend 02/10] Store parent BDS in BdrvChild Wen Congyang
2015-12-02  5:31 ` [Qemu-devel] [Patch v12 resend 03/10] Backup: clear all bitmap when doing block checkpoint Wen Congyang
2015-12-02  5:31 ` [Qemu-devel] [Patch v12 resend 04/10] Allow creating backup jobs when opening BDS Wen Congyang
2015-12-02  5:31 ` [Qemu-devel] [Patch v12 resend 05/10] docs: block replication's description Wen Congyang
2015-12-23  9:26   ` Stefan Hajnoczi
2016-01-04  6:03     ` Wen Congyang
2016-01-26 13:57       ` Stefan Hajnoczi
2016-01-04 15:51     ` Dr. David Alan Gilbert
2015-12-02  5:31 ` [Qemu-devel] [Patch v12 resend 06/10] Add new block driver interfaces to control block replication Wen Congyang
2015-12-02  5:31 ` [Qemu-devel] [Patch v12 resend 07/10] quorum: implement block driver interfaces for " Wen Congyang
2015-12-02  5:37 ` [Qemu-devel] [Patch v12 resend 08/10] Implement new driver " Wen Congyang
2015-12-23  9:47   ` Stefan Hajnoczi
2016-01-04  5:50     ` Wen Congyang [this message]
2016-01-26 14:27       ` Stefan Hajnoczi
2015-12-02  5:37 ` [Qemu-devel] [Patch v12 resend 09/10] support replication driver in blockdev-add Wen Congyang
2015-12-02  5:38 ` [Qemu-devel] [Patch v12 resend 10/10] Add a new API to start/stop replication, do checkpoint to all BDSes Wen Congyang
2015-12-17  6:22 ` [Qemu-devel] [Patch v12 resend 00/10] Block replication for continuous checkpoints Wen Congyang
2015-12-23 10:04   ` Stefan Hajnoczi
2016-01-04  5:27     ` Wen Congyang
2016-01-04 16:03       ` Dr. David Alan Gilbert

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=568A0830.2020301@cn.fujitsu.com \
    --to=wency@cn.fujitsu.com \
    --cc=arei.gonglei@huawei.com \
    --cc=dgilbert@redhat.com \
    --cc=eddie.dong@intel.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=mrhines@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=yunhong.jiang@intel.com \
    --cc=zhang.zhanghailiang@huawei.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.