Re: [Qemu-block] [PATCH v4 3/4] block: add a 'blockdev-snapshot' QMP command

[Kevin Wolf]

Am 22.09.2015 um 11:21 hat Alberto Garcia geschrieben:
> On Fri 18 Sep 2015 04:49:06 PM CEST, Eric Blake <address@hidden> wrote:
> 
> >> +# @BlockdevSnapshot
> >> +#
> >> +# @device: device or node name to generate the snapshot from.
> >
> > I'm still wondering if 'node' is a better name than 'device' here.
> 
> I don't have a strong preference. Kevin, Max, ... any opinions?

If I had to choose, I think I would go with 'node' indeed.

> >> +#
> >> +# @snapshot: reference to the existing block device that will be used
> >> +#            for the snapshot. It must not have a current backing file
> >> +#            (this can be achieved by passing "backing": "" to
> >> +#            blockdev-add).
> >
> > Possibly confusing terminology.
> >
> > Let's consider: the act of creating a snapshot says to go from:
> >
> > image1 [read-write]
> >
> > to
> >
> > image1 [read-only] <- image2 [read-write]
> >
> > that is, image1 is now the snapshot of the state in time we executed the
> > command, and image2 is the delta from what happened since the snapshot.
> >  Therefore, image2 is NOT the snapshot.  Naming the command
> > 'blockdev-snapshot' is fine, but I think we can have better names for
> > the arguments.
> >
> > Better wording might be:
> >
> > @device: device or node that will have a snapshot created
> >
> > @overlay: reference to existing block device that will become the
> > overlay of device, as part of creating the snapshot. It must not have
> > a current backing file...
> 
> I think you are right. I'll update the descriptions as you suggest.
> 
> The problem is that, incorrectly or not, we are already using 'snapshot'
> to refer to the overlays, e.g in BlockdevSnapshotSync:

Let's not worry too much about legacy commands. We know that we made
some decisions in the past that we wouldn't make today. As long as we
don't introduce new commands, it makes little sense to clean them up, as
the requirement to maintain compatibility would result in an even worse
API in the end. But for new commands, we can choose whatever we think
makes most sense in the future.

Kevin