Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command

[Markus Armbruster]

Max Reitz <address@hidden> writes:

> On 01.02.2017 13:28, Daniel P. Berrange wrote:
>> On Wed, Feb 01, 2017 at 01:23:54PM +0100, Max Reitz wrote:
>>> On 01.02.2017 13:16, Daniel P. Berrange wrote:
>>>> On Wed, Feb 01, 2017 at 01:13:39PM +0100, Max Reitz wrote:
>>>>> On 30.01.2017 19:37, Eric Blake wrote:
>>>>>> On 01/26/2017 07:27 AM, Daniel P. Berrange wrote:
>>>>>>> On Thu, Jan 26, 2017 at 08:35:30PM +0800, Fam Zheng wrote:
>>>>>>>> On Thu, 01/26 11:04, Daniel P. Berrange wrote:
>>>>>>>>> The -n arg to the convert command allows use of a pre-existing image,
>>>>>>>>> rather than creating a new image. This adds a -n arg to the dd command
>>>>>>>>> to get feature parity.
>>>>>>>>
>>>>>>>> I remember there was a discussion about changing qemu-img dd's default 
>>>>>>>> to a
>>>>>>>> "conv=nocreat" semantic, if so, "-n" might not be that useful. But 
>>>>>>>> that part
>>>>>>>> hasn't made it into the tree, and I'm not sure which direction we 
>>>>>>>> should take.
>>>>>>>> (Personally I think default to nocreat is a good idea).
>>>>>>>
>>>>>>> Use nocreat by default would be semantically different from real "dd"
>>>>>>> binary which feels undesirable if the goal is to make "qemu-img dd"
>>>>>>> be as consistent with "dd" as possible.
>>>>>>>
>>>>>>> It would be trivial to rewrite this patch to add support for the "conv"
>>>>>>> option, allowing the user to explicitly give 'qemu-img dd conv=nocreat'
>>>>>>> instead of my 'qemu-img dd -n' syntax, without changing default 
>>>>>>> semantics.
>>>>>>
>>>>>> Adding 'conv=nocreat' (and not '-n') feels like the right way to me.
>>>>>
>>>>> The original idea was to make conv=nocreat a mandatory option, I think.
>>>>> qemu-img was supposed error out if the user did not specify it.
>>>>
>>>> I'm not really seeing a benefit in doing that - it would just break
>>>> existing usage of qemu-img dd for no obvious benefit.
>>>
>>> Well... Is there existing usage?
>> 
>> It shipped in 2.8.0 though, so imho that means we have to assume there
>> are users, and thus additions must to be backwards compatible from now
>> on.
>
> Depends. I don't think there are too many users, so we could still
> justify a change if there's a very good reason for it.
>
> I do agree that it's probably not a very good reason, though.
>
>>> The benefit would be that one could (should?) expect qemu-img dd to
>>> behave on disk images as if they were block devices; and dd to a block
>>> device will not truncate or "recreate" it.
>>>
>>> If you don't give nocreat, it's thus a bit unclear whether you want to
>>> delete and recreate the target or whether you want to write into it.
>>> Some may expect qemu-img dd to behave as if the target is a normal file
>>> (delete and recreate it), others may expect it's treated like a block
>>> device (just write into it). If you force the user to specify nocreat,
>>> it would make the behavior clear.
>>>
>>> (And you can always delete+recreate the target with qemu-img create.)
>>>
>>> It's all a bit complicated. :-/
>> 
>> If the goal is to be compatible with /usr/bin/dd then IIUC, the behaviour
>> needs to be
>> 
>>  - If target is a block device, then silently assume nocreat|notrunc
>>    is set, even if not specified by user
>> 
>>  - If target is a file, then silently create & truncate the file
>>    unless nocreat or notrunc are set
>
> Yes. But you could easily argue that every image file is a "block device".

No.  /bin/dd treats exactly block special files as block special files,
so the qemu-img command that tries to behave like it should do, too.

In case you say that's inconvenient: pretty much everything about dd's
archaic user interface is inconvenient.  If you want convenient, roll
your own.  If you want familiar, stick to the original.