On 07/12/2017 01:00 PM, Max Reitz wrote: > On 2017-07-12 16:56, Kevin Wolf wrote: >> 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. > > Works for me. > > Max >
Sold, thanks for the idea. (Feel free to quabble on "unsafe" in the upcoming patch, I'm not sold on that either, but I wanted it to match the -u flag for rebase.) ((Maybe I'll keep it as -u but pretend it stands for --unchecked or some such nonsense.))
