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
pgpgeiYshcQdV.pgp
Description: PGP signature