On Mon, Nov 20, 2023 at 05:23:27PM -0600, Eric Blake wrote: > > I'm interested in this use case, and I think that the method would be > > as simple as this: > > > > 1. Decide a cluster size for the output qcow2 file. > > 2. Read the input file once to determine which clusters need to be > > allocated in the output file and which ones don't. > > 3. That infomation is enough to determine the number and contents of > > the refcount table, refcount blocks, and L1/L2 tables. > > 4. Write the qcow2 header + metadata + allocated data to stdout. > > It may also be possible to write a qcow2 file that uses the external > data bit, so that you are only writing the qcow2 header + metadata, > and reusing the existing input file as the external data.
Sure, although I'm not so certain about the use case here... also, the input file might not be raw. > > Because this would be an external tool it would only support > > a qcow2 file with the default options. Other features like > > compression would be out of scope. > > Why is compression not viable? Are you worried that the qcow2 > metadata (such as refcounts) becomes too complex? Yeah, mostly... also, since the output file would be streamable it's trivial to pipe it through gzip or whatever. > I've also wondered how easy or hard it would be to write a tool that > can take an existing qcow2 file and defragment and/or compress it > in-place (rather than having to copy it to a second qcow2 file). That sounds a bit more complex, but I guess it's doable. But not something that I need atm :) Berto
