On 08/29/2017 10:30 AM, Eric Blake wrote:
> On 08/28/2017 08:18 PM, John Snow wrote:
>>>> We'd have to develop a new syntax for specifying these resources that
>>>> can be stored in a qcow2 file,
>>>
>>> It's called the json-pseudo-protocol and was developed exactly for this.
>>>
>>
>> That's what I was hinting at for "or otherwise co-opt an existing
>> syntax" but I was unaware that it was intended for "exactly" this.
>>
>> Do we actually use it in any on-disk format, currently? qcow2 only lets
>> you specify simple filenames in the qcow2 metadata, right?
>
> You can specify json-pseudo backing names both on the command line AND
> embedded in the qcow2 file itself (within the length limits imposed by
> the qcow2 header size). Yes, this means it is already possible to
> create qcow2 files that can only be opened by qemu (or else teaching
> your alternative program how to parse qemu's json-pseudo-protocol).
>
>>
>>>> or otherwise co-opt an existing syntax
>>>> in-use by QEMU. This syntax would likely be useful only to QEMU, which
>>>> would steer the qcow2 format in a direction not too useful by other
>>>> emulators, and qcow2 is an open format, so we may want to avoid this.
>>>
>>> Storing a file name in the backing link field that cannot be interpreted
>>> by other programs is in my opinion still very much better than not
>>> storing any information whatsoever, because in the former case other
>>> programs can at least say "sorry, I have no idea what this means" (or
>>> maybe they can indeed interpret it, who knows), whereas in the latter
>>> they may not even know that the qcow2 image is incomplete.
>>>
>>
>> I don't disagree personally, but I seem to recall that Kevin was adamant
>> that the qcow2 bitmap extension should remain useful and semantically
>> meaningful to third parties, so I try to keep that in mind. Maybe I
>> should let him chime in instead of try to "concern troll" my own
>> suggestions into the ground.
>
> We already have that situation today, but you are right to worry about
> whether making it even more prevalent is something we can try to minimize.
>
Proposal distillate:
(1) Specify relationship on CLI, QCOW becomes a bitmap-child of any
arbitrary node.
Pros: Easy to implement
Adds bitmap support to literally everything
Cons: Bitmap has no semantic link to data it describes
Relationship must be re-specified every launch
Max and Kevin are firmly NACK
(2) Raw file becomes a R/W backing file of the QCOW2, implemented as
either a bitmap-child or a more traditional backing file that can
additionally service writes
Pros: Easy to understand
relationship between files exists outside of the QEMU process
Adds bitmap support to just about everything that can be expressed
via JSON
Cons: All but necessitates QEMU-specific syntax in a qcow2 file
Depending on implementation, possibly messy in bdrv_open
Adding bitmaps to non-qcow2 files after open makes the launch CLI
invalid for future launches (Not any different to snapshots.)
(3) Add a raw-like mapping mode to QCOW2 instead, skipping the whole affair
Pros: Adds a nice, performant hybrid mode to qcow2
Solves the problem of "bitmaps for raw" more or less
Avoids bdrv_open() complications
Avoids writing qemu-specific jargon in qcow2 files
Cons: Doesn't actually add arbitrary bitmaps to any file format
Users are still gonna ask for bitmaps for other formats anyway
I think I like 2 or 3 -- or perhaps indeed two AND three. The qcow2-raw
mode sounds like something we ought to have anyway. I'll try to start an
RFC.
--js
