On 2017-11-14 21:38, John Snow wrote: > > > On 11/14/2017 03:35 PM, Max Reitz wrote: >> On 2017-11-14 21:30, John Snow wrote: >>> >>> >>> On 11/14/2017 01:46 PM, Max Reitz wrote: >>>> On 2017-11-14 19:45, Thomas Huth wrote: >>>>> On 14.11.2017 14:32, Max Reitz wrote: >>>>> [...] >>>>>> Well, do you want to document it? I'd rather deprecate it altogether. >>>>> >>>>> Maybe a first step could be to change qemu-img so that it refuses to >>>>> create new qcow1 images (but still can convert them into other formats). >>>>> So basically make qcow1 read-only? >>>> >>>> Yep, and the actual first step to that is to make it issue a deprecation >>>> warning when creating qcow v1 images (which is what I proposed). :-) >>>> >>>> Max >>>> >>> >>> Deprecation warning is good. >>> >>> In future versions you can shimmy it behind a >>> --no-really-I-want-this-old-format option, I think we ought to support >>> creating the images for as long as is technologically convenient. >> >> Well, at some point you can also demand from users to just dig out some >> old version of qemu-img to convert their qcow v1 images to qcow2. It's >> not like they are going to miss out on anything. >> > > As long is convenient. I won't throw a fit that it needs to be around > forever, but as long as it's sufficiently guarded from use and isn't > hard to keep around I'd prefer to do that. > > I suppose it's just a weak preference.
I agree that sufficiently guarding it (albeit our definitions on what is sufficient may differ) serves all the purpose I need, that is, make users aware of the fact that they are doing something for which I can see no reason. But on the other hand, I want those guards to make it dead code, effectively. And if something is dead code... There is no reason to keep it around. >> (If you deprecate emulated hardware, users may complain that they don't >> get the newest qemu features/bugfixes/... while continuing to use that >> hardware, so I can see that it's a tough decision whether to deprecate >> that. But it's not like you are going to lose any features or anything >> if you convert your dusty images to qcow2. On the contrary, we're >> helping you to get more performance out of them. Maybe qemu should just >> silently convert qcow v1 images to qcow2 without asking the user, like >> Apple did...) >> >> Max >> > > "Like Apple did" seems sufficient justification to never do that, but > maybe that's just my own opinion. Sorry, forgot the emoticon. :-) Yes, that was meant to be a joke. Although adding a qemu-img amend for amending qcow v1 to v2/v3 images is probably mostly an issue of creating the right internal interface for cross-format amendments. (Silently storing qcow v1 as v2/v3 images is actually something where users could have a problem because maybe they have some tool that only works on qcow v1 images; and then they can't use that together with an auto-amending qemu...) Max
signature.asc
Description: OpenPGP digital signature