From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHslf-00051f-Hc for qemu-devel@nongnu.org; Fri, 06 Sep 2013 05:56:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHslX-0004SQ-GI for qemu-devel@nongnu.org; Fri, 06 Sep 2013 05:55:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHslX-0004SC-78 for qemu-devel@nongnu.org; Fri, 06 Sep 2013 05:55:47 -0400 Date: Fri, 6 Sep 2013 11:55:38 +0200 From: Kevin Wolf Message-ID: <20130906095538.GF2588@dhcp-200-207.str.redhat.com> References: <20130903162449.GF5285@irqsave.net> <20130906075606.GD4814@T430s.nay.redhat.com> <20130906084513.GE2588@dhcp-200-207.str.redhat.com> <20130906091820.GA24154@T430s.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130906091820.GA24154@T430s.nay.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Block Filters List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , jcody@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, pbonzini@redhat.com, mreitz@redhat.com Am 06.09.2013 um 11:18 hat Fam Zheng geschrieben: > On Fri, 09/06 10:45, Kevin Wolf wrote: > > Am 06.09.2013 um 09:56 hat Fam Zheng geschrieben: > > > Since BlockDriver.bdrv_snapshot_create() is an optional operation, = blockdev.c > > > can navigate down the tree from top node, until hitting some layer = where the op > > > is implemented (the QCow2 bs), so we get rid of this top_node_below= _filter > > > pointer. > >=20 > > Is it even inherent to a block driver (like a filter), if a snapshot = is > > to be taken at its level? Or is it rather a policy decision that shou= ld > > be made by the user? > >=20 > OK, getting the point that user should have full flexibility and fine o= peration > granularity. It also stands against block_backend->top_node_below_filte= r. Do we > really have the assumption that all the filters are on top of the tree = and linear? > Shouldn't this be possible? >=20 > Block Backend > | > | > Quodrum BDS > / | \ > iot filter | \ > / | \ > qcow2 qcow2 qcow2 >=20 > So we throttle only a particular image, not the whole device. But this = will > make a top_node_below_filter pointer impossible. I was assuming that Beno=EEt's model works for the special case of snapshotting in one predefined way, but this is actually a very good example of why it doesn't. The approach relies on snapshotting siblings together, and in this case the siblings would be iot/qcow2/qcow2, while iot is still a filter. This would mean that either iot needs to be top_node_below_filter and throttling doesn't stay on top, or the left qcow2 is top_node_below_filter and the other Quorum images aren't snapshotted. > > In our example, the quorum driver, it's not at all clear to me that y= ou > > want to snapshot all children. In order to roll back to a previous > > state, one snapshot is enough, you don't need multiple copies of the > > same one. Perhaps you want two so that we can still compare them for > > verification. Or all of them because you can afford the disk space an= d > > want ultimate safety. I don't think qemu can know which one is true. > >=20 > Only if quorum ever knows about and operates on snapshots, it should be > considered specifically, but no. So we need to achieve this in the gene= ral > design: allow user to take snapshot, or set throttle limits on particul= ar > BDSes, as above graph. >=20 > > In the same way, in a typical case you may want to keep I/O throttlin= g > > for the whole drive, including the new snapshot. But what if the > > throttling was used in order to not overload the network where the im= age > > is stored, and you're now doing a local snapshot, to which you want t= o > > stream the image? The I/O throttling should apply only to the backing > > file, not the new snapshot. > >=20 > Yes, and OTOH, throttling really suits to be a filter only if it can be= a non > top one, otherwise it's no better than what we have now. Well, it would be a cleaner architecture in any case, but having it in the middle of the stack feels useful indeed, so we should support it. > > So perhaps what we really need is a more flexible snapshot/BDS tree > > manipulation command that describes in detail which structure you wan= t > > to have in the end. Designing the corresponding QMP command is the hard part, I guess. Kevin