From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQs3p-0004p4-Ka for qemu-devel@nongnu.org; Thu, 26 Feb 2015 01:36:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQs3k-00059I-Lu for qemu-devel@nongnu.org; Thu, 26 Feb 2015 01:36:37 -0500 Received: from [59.151.112.132] (port=1436 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQs3j-00058K-Nn for qemu-devel@nongnu.org; Thu, 26 Feb 2015 01:36:32 -0500 Message-ID: <54EEBF7C.3010504@cn.fujitsu.com> Date: Thu, 26 Feb 2015 14:38:52 +0800 From: Wen Congyang MIME-Version: 1.0 References: <1423710438-14377-1-git-send-email-wency@cn.fujitsu.com> <1423710438-14377-2-git-send-email-wency@cn.fujitsu.com> <20150212072117.GB32554@ad.nay.redhat.com> <54DC58E6.7060608@cn.fujitsu.com> <20150212084435.GD32554@ad.nay.redhat.com> <54EC2D3F.2030803@cn.fujitsu.com> <20150225024622.GC9178@ad.nay.redhat.com> In-Reply-To: <20150225024622.GC9178@ad.nay.redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 01/14] docs: block replication's description List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , Lai Jiangshan , Jiang Yunhong , Dong Eddie , qemu devel , "Dr. David Alan Gilbert" , Gonglei , Stefan Hajnoczi , Paolo Bonzini , Yang Hongyang , jsnow@redhat.com, zhanghailiang On 02/25/2015 10:46 AM, Fam Zheng wrote: > On Tue, 02/24 15:50, Wen Congyang wrote: >> On 02/12/2015 04:44 PM, Fam Zheng wrote: >>> On Thu, 02/12 15:40, Wen Congyang wrote: >>>> On 02/12/2015 03:21 PM, Fam Zheng wrote: >>>>> Hi Congyang, >>>>> >>>>> On Thu, 02/12 11:07, Wen Congyang wrote: >>>>>> +== Workflow == >>>>>> +The following is the image of block replication workflow: >>>>>> + >>>>>> + +----------------------+ +------------------------+ >>>>>> + |Primary Write Requests| |Secondary Write Requests| >>>>>> + +----------------------+ +------------------------+ >>>>>> + | | >>>>>> + | (4) >>>>>> + | V >>>>>> + | /-------------\ >>>>>> + | Copy and Forward | | >>>>>> + |---------(1)----------+ | Disk Buffer | >>>>>> + | | | | >>>>>> + | (3) \-------------/ >>>>>> + | speculative ^ >>>>>> + | write through (2) >>>>>> + | | | >>>>>> + V V | >>>>>> + +--------------+ +----------------+ >>>>>> + | Primary Disk | | Secondary Disk | >>>>>> + +--------------+ +----------------+ >>>>>> + >>>>>> + 1) Primary write requests will be copied and forwarded to Secondary >>>>>> + QEMU. >>>>>> + 2) Before Primary write requests are written to Secondary disk, the >>>>>> + original sector content will be read from Secondary disk and >>>>>> + buffered in the Disk buffer, but it will not overwrite the existing >>>>>> + sector content in the Disk buffer. >>>>> >>>>> I'm a little confused by the tenses ("will be" versus "are") and terms. I am >>>>> reading them as "s/will be/are/g" >>>>> >>>>> Why do you need this buffer? >>>> >>>> We only sync the disk till next checkpoint. Before next checkpoint, secondary >>>> vm write to the buffer. >>>> >>>>> >>>>> If both primary and secondary write to the same sector, what is saved in the >>>>> buffer? >>>> >>>> The primary content will be written to the secondary disk, and the secondary content >>>> is saved in the buffer. >>> >>> I wonder if alternatively this is possible with an imaginary "writable backing >>> image" feature, as described below. >>> >>> When we have a normal backing chain, >>> >>> {virtio-blk dev 'foo'} >>> | >>> | >>> | >>> [base] <- [mid] <- (foo) >>> >>> Where [base] and [mid] are read only, (foo) is writable. When we add an overlay >>> to an existing image on top, >>> >>> {virtio-blk dev 'foo'} {virtio-blk dev 'bar'} >>> | | >>> | | >>> | | >>> [base] <- [mid] <- (foo) <---------------------- (bar) >>> >>> It's important to make sure that writes to 'foo' doesn't break data for 'bar'. >>> We can utilize an automatic hidden drive-backup target: >>> >>> {virtio-blk dev 'foo'} {virtio-blk dev 'bar'} >>> | | >>> | | >>> v v >>> >>> [base] <- [mid] <- (foo) <----------------- (hidden target) <--------------- (bar) >>> >>> v ^ >>> v ^ >>> v ^ >>> v ^ >>> >>>> drive-backup sync=none >>>> >>> >>> So when guest writes to 'foo', the old data is moved to (hidden target), which >>> remains unchanged from (bar)'s PoV. >>> >>> The drive in the middle is called hidden because QEMU creates it automatically, >>> the naming is arbitrary. >> >> I don't understand this. In which function, the hidden target is created automatically? >> > > It's to be determined. This part is only in my mind :) What about this: -drive file=nbd-target,if=none,id=nbd-target0 \ -drive file=active-disk,if=virtio,driver=qcow2,backing.file.filename=hidden-disk,backing.driver=qcow2,backing.backing=nbd-target0 Thanks Wen Congyang > > Fam >