From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlDaA-0004AP-2t for qemu-devel@nongnu.org; Thu, 23 Apr 2015 05:38:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlDa9-000209-4n for qemu-devel@nongnu.org; Thu, 23 Apr 2015 05:38:06 -0400 Date: Thu, 23 Apr 2015 11:37:54 +0200 From: Kevin Wolf Message-ID: <20150423093754.GD5289@noname.redhat.com> References: <1428055280-12015-1-git-send-email-wency@cn.fujitsu.com> <1428055280-12015-2-git-send-email-wency@cn.fujitsu.com> <20150420153047.GB32653@stefanha-thinkpad.redhat.com> <5535A727.5080402@cn.fujitsu.com> <55366C81.1080202@redhat.com> <20150422093101.GD3882@noname.redhat.com> <5537742A.90504@redhat.com> <20150423090031.GB5289@noname.redhat.com> <5538BABF.7040401@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5538BABF.7040401@redhat.com> Subject: Re: [Qemu-devel] [PATCH COLO v3 01/14] docs: block replication's description List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Fam Zheng , Lai Jiangshan , qemu block , Jiang Yunhong , Dong Eddie , qemu devel , Max Reitz , Gonglei , Stefan Hajnoczi , Yang Hongyang , "Dr. David Alan Gilbert" , zhanghailiang Am 23.04.2015 um 11:26 hat Paolo Bonzini geschrieben: > > > On 23/04/2015 11:00, Kevin Wolf wrote: > > Because it may be the right design. > > > > If you're really worried about the test matrix, put a check in the > > filter block driver that its bs->file is qcow2. Of course, such an > > artificial restriction looks a bit ugly, but using a bad design just > > in order to get the same restriction is even worse. > > > > Stefan originally wanted to put image streaming in the QED driver. I > > think we'll agree today that it was right to reject that. It's simply > > not functionality related to the format. Adding replication logic to > > qcow2 looks similar to me in that respect. > > Yes, I can't deny it is similar. Still, there is a very important > difference: limiting colo's internal workings to qcow2 or NBD doesn't > limit what the user can do (while streaming limited the user to image > files in QED format). > > It may also depend on how the patches look like and how much the colo > code relies on other internal state. > > For NBD the answer is almost nothing, and you don't even need a filter > driver. You only need to separate sharply the "configure" and "open" > phases. So it may indeed be possible to generalize the handling of the > secondary to non-NBD. > > It may be the same for the primary; I admit I haven't even tried to read > the qcow2 patch, as I couldn't do a meaningful review. The qcow2 patch only modifies two existing lines. The rest it adds is a the qcow2+colo BlockDriver, which references some qcow2 functions directly and has a wrapper for others. On a quick scan, it didn't seem like it accesses any internal qcow2 variables or calls any private functions. In other words, it's the perfect example for a filter. Kevin