qemu-block
[Top][All Lists]
Advanced

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

Re: [PATCH v2 1/1] qemu-img: do not erase destination file in qemu-img d


From: Denis V. Lunev
Subject: Re: [PATCH v2 1/1] qemu-img: do not erase destination file in qemu-img dd command
Date: Wed, 1 Nov 2023 18:03:36 +0100
User-agent: Mozilla Thunderbird

On 11/1/23 17:51, Daniel P. Berrangé wrote:
On Tue, Oct 31, 2023 at 03:33:52PM +0100, Hanna Czenczek wrote:
On 01.10.23 22:46, Denis V. Lunev wrote:
Can you please not top-post. This makes the discussion complex. This
approach is followed in this mailing list and in other similar lists
like LKML.

On 10/1/23 19:08, Mike Maslenkin wrote:
I thought about "conv=notrunc", but my main concern is changed virtual
disk metadata.
It depends on how qemu-img used.
May be I followed to wrong pattern, but pros and cons of adding "conv"
parameter was not in my mind in scope of the first patch version.
I see 4 obvious ways of using `qemu-img dd`:
1. Copy virtual disk data between images of same format. I think disk
geometry must be preserved in this case.
2. Copy virtual disk data between different formats. It is a valid
pattern? May be `qemu-img convert` should to be used instead?
3. Merge snapshots to specified disk image, i.e read current state and
write it to new disk image.
4. Copy virtual disk data to raw binary file. Actually this patch
breaks 'dd' behavior for this case when source image is less (in terms
of logical blocks) than existed raw binary file.
      May be for this case condition can be improved to smth like
     if (strcmp(fmt, "raw") || !g_file_test(out.filename,
G_FILE_TEST_EXISTS)) . And parameter "conv=notrunc" may be implemented
additionally for this case.
My personal opinion is that qemu dd when you will need to
extract the SOME data from the original image and process
it further. Thus I use it to copy some data into raw binary
file. My next goal here would add ability to put data into
stdout that would be beneficial for. Though this is out of the
equation at the moment.

Though, speaking about the approach, I would say that the
patch changes current behavior which is not totally buggy
under a matter of this or that taste. It should be noted that
we are here in Linux world, not in the Mac world where we
were in position to avoid options and selections.

Thus my opinion that original behavior is to be preserved
as somebody is relying on it. The option you are proposing
seems valuable to me also and thus the switch is to be added.
The switch is well-defined in the original 'dd' world thus
either conv= option would be good, either nocreat or notrunc.
For me 'nocreat' seems more natural.

Anyway, the last word here belongs to either Hanna or Kevin ;)
Personally, and honestly, I see no actual use for qemu-img dd at all,
because we’re trying to mimic a subset of an interface of a rather complex
program that has been designed to do what it does. We can only fail at
that.  Personally, whenever I need dd functionality, I use
qemu-storage-daemon’s fuse export, and then use the actual dd program on
top.  Alternatively, qemu-img convert is our native interface;
unfortunately, its feature set is lacking when compared to qemu-img dd, but
I think it would be better to improve that rather than working on qemu-img
dd.
Is there a clear view of what gaps exist in 'qemu-img convert', and more
importantly, how much work is it to close the gaps, such that 'dd' could
potentially be deprecated & eventually removed ?

I am using 'qemu-img dd' as a way to get (some) content
from the image. I have dreamed about getting it to
stdout.

Den



reply via email to

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