On Wed, 12 Jun 2024 12:21, Alberto Garcia <be...@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
