From: Alberto Garcia <berto@igalia.com>
To: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>,
qemu-block@nongnu.org, qemu-devel@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 11:21:32 +0200 [thread overview]
Message-ID: <w511q52ms83.fsf@igalia.com> (raw)
In-Reply-To: <eye51.7m7tedycfrgc@linaro.org>
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
next prev parent reply other threads:[~2024-06-12 9:22 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 [this message]
2024-06-12 11:25 ` Manos Pitsidianakis
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=w511q52ms83.fsf@igalia.com \
--to=berto@igalia.com \
--cc=eblake@redhat.com \
--cc=hreitz@redhat.com \
--cc=javed@igalia.com \
--cc=kwolf@redhat.com \
--cc=manos.pitsidianakis@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).