Re: [PATCH v5 3/7] qcow: Tolerate backing_fmt=, but warn on backing_fmt=raw

On 5/5/20 2:35 AM, Kevin Wolf wrote: Prior to this patch, -F does not work with qcow. And even with this patch, we still cannot store the explicit value of -F in the qcow file. Anything that does not use -F must continue to work for now (although it may now warn, and in fact must warn if we deprecate it), while anything explicit is free to fail (since it failed already), but could also be made to work (if letting it work is nicer than making it fail, and where "work" may still include a warning, although it's pointless to have something brand new that works but is deprecated out of the box). So the following is my summary of the two options we can choose between: Option 1, qcow backed by raw is more common than qcow backed by other, so we want: raw <- qcow, no -F: work without warning (but if backing file is edited, a future probe seeing non-raw would break image) raw <- qcow, with -F: work without warning (but if backing file is edited, a future probe seeing non-raw would break image) other <- qcow, no -F: works but issues a warning (but backing file will always probe correctly) other <- qcow, with -F: fails (we cannot honor the user's explicit request, because we would still have to probe) Option 2, qcow backed by other is more common than qcow backed by raw, so we want: raw <- qcow, no -F: works but issues a warning (using a raw backing file without explicit buy-in is risky) raw <- qcow, with -F: works but issues a warning (explicit buy-in will still require subsequent probing, and a backing file could change which would break image) other <- qcow, no -F: works without warning other <- qcow, with -F: works without warning (later probing will still see non-raw) It looks like you are leaning more towards option 1, while my patch leaned more towards option 2. Anyone else want to chime in with an opinion on which is safer vs. easier? If we go with option 2, are we trying to deprecate ALL use of raw as a backing file to qcow, regardless of whether the user was explicit about it? If we go with option 1, then we are instead deprecating any use of non-raw as a backing file to qcow. At the end of the day, we are trying to discourage users from creating new qcow files in the first place; qcow2 is much better. We still have to read existing qcow images with backing files, but maybe we want: Option 3: completely deprecate qcow images with backing files, as there is no safe way to do things favoring either raw (option 1) or non-raw (option 2), and therefore accept -F solely for convenience with the rest of the series, but always issue a warning regardless of whether -F was present. Once we decide which behavior we want, I'll make sure the commit message matches the behavior. Remember, for implicit images, we are starting a deprecation clock; for explicit images, it previously failed, so continuing to fail is still viable. Indeed, I can make the test more robust. But more importantly, we need consensus on _what_ we want behavior to be, and write the test along those lines. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org