All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alberto Garcia <berto@igalia.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-block@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
	Hanna Czenczek <hreitz@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: Converting images to stdout
Date: Wed, 22 Nov 2023 12:15:32 +0000	[thread overview]
Message-ID: <ZV3w5A-8Kid-9-5W@igalia.com> (raw)
In-Reply-To: <6hipeyoml7qpxcycxbydmldohcwsle56tpeavzddpciycb4vfm@gmr7uf56skye>

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


      reply	other threads:[~2023-11-22 12:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-16 17:48 Converting images to stdout Alberto Garcia
2023-11-20 23:23 ` Eric Blake
2023-11-22 12:15   ` Alberto Garcia [this message]

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=ZV3w5A-8Kid-9-5W@igalia.com \
    --to=berto@igalia.com \
    --cc=eblake@redhat.com \
    --cc=hreitz@redhat.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.