From: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
To: Alberto Garcia <berto@igalia.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: qemu-block@nongnu.org, Eric Blake <eblake@redhat.com>,
Kevin Wolf <kwolf@redhat.com>, Hanna Czenczek <hreitz@redhat.com>,
Madeeha Javed <javed@igalia.com>
Subject: Re: [PATCH] scripts/qcow2-to-stdout.py: Add script to write qcow2 images to stdout
Date: Wed, 12 Jun 2024 14:25:20 +0300 [thread overview]
Message-ID: <eyt3m.ivfg6ce1i6n6@linaro.org> (raw)
In-Reply-To: <w511q52ms83.fsf@igalia.com>
On Wed, 12 Jun 2024 12:21, Alberto Garcia <berto@igalia.com> wrote:
>On Wed 12 Jun 2024 09:01:01 AM +03, Manos Pitsidianakis wrote:
>> Hello Alberto,
>
>Hello Manos!
>
>> > This is equivalent to using qemu-img to convert a file to qcow2 and
>> > then writing the result to stdout, with the difference that this
>> > tool does not need to create this temporary qcow2 file and therefore
>> > does not need any additional disk space.
>>
>> Can you expand on this a little bit? Would modifying qemu-img to write
>> to stdout if given, say, - instead of a file output path be enough to
>> make this script unnecessary?
>
>Yes, it would be enough. Allowing qemu-img convert to write to stdout
>would indeed be very nice for the end user but it's a bit of a niche use
>case and it's also not a trivial task so I don't think that it's worth
>the effort. The output files that you pass to qemu-img convert need to
>be seekable because the only way to produce a qcow2 file without doing
>that is by precalculating all the metadata in advance before starting to
>write anything (that's why this script reads the input file twice).
>
>This is fundamentally different to what qemu-img convert does, which is
>to read the input file from start to finish and write it to the output
>file, relying on the relevant driver's existing write operations. All
>those assume random access to the output file.
>
>qemu-img is also much more generic in the sense that it supports many
>different output formats and image options.
>
>In contrast, writing the algorithm for a basic subset of qcow2 is quite
>simple and that's why I think that it makes sense to do it in a separate
>tool.
>
>Berto
Thanks for the complete explanation! It makes sense. Maybe add it to the
commit message as well, it's informative.
Manos
next prev parent reply other threads:[~2024-06-12 11:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-10 14:47 [PATCH] scripts/qcow2-to-stdout.py: Add script to write qcow2 images to stdout Alberto Garcia
2024-06-12 6:01 ` Manos Pitsidianakis
2024-06-12 9:21 ` Alberto Garcia
2024-06-12 11:25 ` Manos Pitsidianakis [this message]
2024-06-12 11:00 ` Manos Pitsidianakis
2024-07-01 8:56 ` Alberto Garcia
2024-07-01 11:07 ` Manos Pitsidianakis
2024-07-01 13:42 ` Alberto Garcia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eyt3m.ivfg6ce1i6n6@linaro.org \
--to=manos.pitsidianakis@linaro.org \
--cc=berto@igalia.com \
--cc=eblake@redhat.com \
--cc=hreitz@redhat.com \
--cc=javed@igalia.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.