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

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3299 bytes --]

First, because this is perhaps the most important thing: I think I
remembered what the original proposal to solve all this mess, or at
least move it to a later point:

We wanted to just disallow overwriting existing files without
conv=notrunc. I think.

The thing is that it's pretty much impossible with the qemu block layer
to determine whether a file exists or not. Maybe you cannot open it but
it would be possible to overwrite it. This is the reason the patches for
this did not make it into 2.8.


On 06.02.2017 11:31, Daniel P. Berrange wrote:
> On Fri, Feb 03, 2017 at 07:56:11PM +0100, Max Reitz wrote:
>>> 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.
>>
>> I agree. But qemu-img dd already is not dd. It interprets disk image
>> files as virtual disks instead of as plain files. The question is
>> whether virtual disks are to be treated as block devices or as files.
>>
>> I don't have a strong opinion on the matter. Either way will surprise
>> some people. The original issue was whether to make nocreat/notrunc a
>> mandatory option, so if we didn't have any backwards compatibility
>> issues, it would be the following two surprises:
>>
>> (1) Don't make nocreat/notrunc mandatory (as it is now). Then people
>>     who expect qemu-img dd to treat image files as block devices will
>>     be surprised that all their data is gone. Bad.
> 
> I don't think people really expect qemu-img to treat image file as if
> they were block devices when operating on the host.
> 
> It is like saying people expect /usr/bin/dd to treat a plain file
> as a block device, because they might use it with losetup later.

That's not a good comparison. Disk images are meant to be used with qemu
(or some other VMM, or, yes, with losetup if it's a raw image). Plain
files can be anything. No, dd does not look into the file to determine
whether it may be a raw disk image or not, but it does execute fstat()
to find out whether it's a plain file or a block device.

Furthermore, you are omitting the sentence where I said that qemu-img dd
does not operate on just the host level. It interprets the disk image
contents, thus it is, in a sense, operating from the guest's
perspective. It's somewhere in between, which is why I argued that some
people may assume it's a guest-level tool. At least it's on the same
level as block jobs are, whatever that may mean.

(Well, it does mean that block jobs with mode=existing do not truncate
the output, but the default is mode=absolute-paths, so they would
overwrite it anyway. So there's that.)

I agree that I would probably not expect qemu-img dd to treat images
like block devices. At least I would test it first. But I stand by the
point that it is conceivable to think so, and thus we have to assume
there are such people.

They may be few, but I reasoned that reality would hit them much harder
than all the rest would be affected if we implemented the opposite behavior.

It's a simple trade-off that we did not consider; or rather that we
considered too late.

I also agree with you that it's too late to change now.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]