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
