[Top][All Lists]

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

Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -

From: Max Reitz
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v1 3/6] qemu-img: add support for -n arg to dd command
Date: Wed, 1 Feb 2017 13:23:54 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

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?

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. :-/


> FYI, I've implemented "conv" with "nocreat" and "notrunc" options
> which i'll post once i've tested some more.
> Regards,
> Daniel

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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