Re: [Qemu-devel] Block Filters

[Fam Zheng]

On Fri, 09/06 11:55, Kevin Wolf wrote:
> 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.
> > > 
> > > 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 should
> > > be made by the user?
> > > 
> > OK, getting the point that user should have full flexibility and fine 
> > operation
> > granularity. It also stands against block_backend->top_node_below_filter. 
> > Do we
> > really have the assumption that all the filters are on top of the tree and 
> > linear?
> > Shouldn't this be possible?
> > 
> >                    Block Backend
> >                          |
> >                          |
> >                     Quodrum BDS
> >                     /    |    \
> >              iot filter  |     \
> >                   /      |      \
> >                 qcow2   qcow2   qcow2
> > 
> > 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ît'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.
> 

I think that user must look at what is there first, rather than do it blindly
on the Block Backend, which is only an entry to the tree behind.  Because
wheather snapshot is supported, depends on what's in the backend. If the tree
is merely a single raw image, nothing can be done. So, Block Backend doesn't
hide things: I think we split it from BDS for putting device related states in
a right place. Users still operates on the BDS for data operations (backup,
snapshot, throttle, etc...), much the same as they currently do. The point of
this design here is that we are able to assemble them to get flexible and
sophisticated configurations.

IMO, snapshotting Quodrum childrens, doesn't sound much different from
snapshotting guest's rg0-disk0, rg0-disk1, rg0-disk2, it requires the knowledge
that they are bound to work together. It's just that the knowledge is from
guest raid configuration, or from Quodrum driver. If Quodrum requires all the
children's snapshot be taken at the same time, like a transactional snapshot on
rg0-disk{0,1,2} must triggered from QMP by user, Quodrum driver must implement
its ->bdrv_snapshot_create() and ensure it.

> > > In our example, the quorum driver, it's not at all clear to me that you
> > > 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 and
> > > want ultimate safety. I don't think qemu can know which one is true.
> > > 
> > 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 general
> > design: allow user to take snapshot, or set throttle limits on particular
> > BDSes, as above graph.
> > 
> > > In the same way, in a typical case you may want to keep I/O throttling
> > > for the whole drive, including the new snapshot. But what if the
> > > throttling was used in order to not overload the network where the image
> > > is stored, and you're now doing a local snapshot, to which you want to
> > > stream the image? The I/O throttling should apply only to the backing
> > > file, not the new snapshot.
> > > 
> > 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 want
> > > to have in the end.
> 
> Designing the corresponding QMP command is the hard part, I guess.
> 

Another concern is that we may do all this with substantial duplication work of
QOM.

Fam