qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v4] qemu-img: Check for backing image if specifi


From: John Snow
Subject: Re: [Qemu-block] [PATCH v4] qemu-img: Check for backing image if specified during create
Date: Wed, 12 Jul 2017 15:08:59 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1


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.))



reply via email to

[Prev in Thread] Current Thread [Next in Thread]