On 2017-08-22 21:07, John Snow wrote: [...]
> (3) Add either a new flag that turns qcow2's backing file into a full > R/W backing file, or add a new extension to qcow2 entirely (bypassing > the traditional backing file mechanism to avoid confusion for older > tooling) that adds a new read-write backing file field. > > This RW backing file field will be used for all reads AND writes; the > qcow2 in question becomes a metadata container on top of the BDS chain. > We can re-use Vladimir's bitmap persistence extension to save bitmaps in > a qcow2 shell. > > The qcow2 becomes effectively a metadata cache for a new (essentially) > filter node that handles features such as bitmaps. This could also be > used to provide allocation map data for RAW files and other goodies down > the road. > > Hopefully this achieves our desire to not create new formats AND our > desire to concentrate features (and debugging, testing, etc) into qcow2, > while allowing users to "have bitmaps with raw files." > > Of course, in this scenario, users now have two files: a qcow2 wrapper > and the actual raw file in question; but regardless of how we were going > to solve this, a raw file necessitates an external file of some sort, > else we give up the idea that it was a raw file. > > > Sound good? While I don't quite like the idea of R/W backing files, I guess "don't quite like" is still rather good. I like how this idea would allow us to use the existing code without putting just arbitrary binary data into the qcow2 file; the data still relates to the virtual disk represented by the qcow2 image. So design-wise, I don't think I have any complaints. As for Kevin, he's on PTO, though. ;-) Max
signature.asc
Description: OpenPGP digital signature
