On 2017-08-29 23:02, John Snow wrote: > > > 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.
I think the only main thing that's missing for implementing (3) is a way to mark allocated clusters to be fall-through-to-backing-file. Max
signature.asc
Description: OpenPGP digital signature
