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

[Max Reitz]

On 01.02.2017 13:40, Daniel P. Berrange wrote:
> On Wed, Feb 01, 2017 at 01:31:01PM +0100, Max Reitz wrote:
>> 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:

[...]

>>>> 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".
> 
> IMHO that would be a bad idea as it would mean different behaviour
> from dd vs qemu-img dd, when run on raw files.

From the perspective of qemu-img, however, a raw file is not a raw file
but a disk image in raw format.

> If we assume nocreat|notrunc behaviour by default, then we would  likely
> need to invent new "creat|trunc" flags to let people turn the previous
> behaviour back on, which would diverge from 'dd' command.

Not really, because you could just use qemu-img create.

I understand your standpoint. I'm just saying there is another
standpoint that also makes a lot of sense and that would imply different
default behavior.

In the end, retaining backwards compatibility will probably win the
discussion automatically, though. That is, always overwrite the target
image by default.


By the way, I plan to integrate all of qemu-img dd's functionality into
qemu-img convert eventually and make qemu-img dd just another interface
for qemu-img convert. Therefore, I'm all in favor of not touch
qemu-img dd until that is done so it doesn't get any more weird behavior
that needs to be supported later.

Max

signature.asc
Description: OpenPGP digital signature