Re: [Qemu-devel] [PATCH v4] qemu-img: Check for backing image if specified during create

[Kevin Wolf]

Am 12.07.2017 um 16:42 hat Eric Blake geschrieben:
> On 05/17/2017 07:38 AM, Max Reitz wrote:
> 
> >>>>>>>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786
> >>>>>>>>
> >>>>>>>> Or, rather, force the open of a backing image if one was specified
> >>>>>>>> for creation. Using a similar -unsafe option as rebase, allow 
> >>>>>>>> qemu-img
> >>>>>>>> to ignore the backing file validation if possible.
> >>>>>>>>
> >>>>>>
> 
> >>> I suspect this is because the backing file is opened somewhere and
> >>> trying to open it breaks now with the locking series applied.
> >>
> >> I think we can legitimately set force-shared=on for opening the backing
> >> file when testing whether the file exists.
> > 
> > For testing whether the file exists, probably. I wouldn't call it
> > legitimately because I don't like making that the default at all, but it
> > should work.
> > 
> > But then we have to differentiate between testing whether the file
> > exists and opening it to read its size; I'm even more wary regarding the
> > latter.
> > 
> > All in all, I've stated my opinion on this matter on IRC: I don't know
> > how much we need this patch. It's nice to have, it's convenient to know
> > you have mistyped the backing filename before you try to use the image
> > in qemu, but it's not critical. I don't consider the current behavior a
> > bug per-se, it's just counterintuitive behavior (that will not cut your
> > head off if you don't know it, though!).
> > 
> 
> The fact that this topic came up on the mailing list again means we
> should probably consider something along these lines for 2.10.
> 
> > (Also, we have a lot of counterintuitive behavior. See this:
> > 
> > $ qemu-img create -f qcow2 sub/backing.qcow2 64M
> > Formatting 'sub/backing.qcow2', fmt=qcow2 size=67108864 encryption=off
> > cluster_size=65536 lazy_refcounts=off refcount_bits=16
> > $ qemu-img create -f qcow2 -b sub/backing.qcow2 sub/top.qcow2
> > qemu-img: sub/top.qcow2: Could not open 'sub/sub/backing.qcow2': No such
> > file or directory
> > 
> > Yeah, sure, you'll know after you've done the mistake once. But the same
> > applies here, too, doesn't it...?)
> > 
> > So for me, it's a question of convenience: How much does the current
> > behavior annoy users? How much annoyance will changing the behavior
> > bring? I'm not (or rather, no longer) convinced the former outweighs the
> > latter, especially since it means having to change management tools
> > (which create external snapshots with qemu-img create while the backing
> > image is in use by qemu).
> > 
> > If you think otherwise, well, you're the main maintainer. :-)
> > 
> > Max
> > 
> > 
> > PS: Can there be a middle ground? Like just printing a warning if the
> > backing file cannot be opened and we don't absolutely have to?
> 
> Middle ground may be harder, but may be nicer (especially since we are
> talking about tightening behavior, making things that used to work now
> fail is not nice if there is not a transition period where it first just
> warns).

We can do the nowadays usual thing: Add a -u option, print a deprecation
warning if we don't have -u and can't open the backing file, and put
it into the list of things to remove in 3.0.

Kevin

pgpfcxX_nfQ4_.pgp
Description: PGP signature