qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Brad Campbell <brad@fnarfbargle.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel@nongnu.org, Brad Campbell <lists2009@fnarfbargle.com>
Subject: Re: [Qemu-devel] Qemu-img convert with -B
Date: Wed, 27 Apr 2011 16:56:36 +0800	[thread overview]
Message-ID: <4DB7DA44.4030008@fnarfbargle.com> (raw)
In-Reply-To: <BANLkTikpekvoS36tQ2XCmeeGfhC3yQ8ihA@mail.gmail.com>

On 27/04/11 16:10, Stefan Hajnoczi wrote:
> On Wed, Apr 27, 2011 at 4:05 AM, Brad Campbell
> <lists2009@fnarfbargle.com>  wrote:
>> I see there is a bug raised about the behaviour of qemu-img when used to convert using an output backing file. It allocates every sector whether or not it already exists in the output backing file.
> Please post the link to the bug report.
>
Yeah, sorry about that. Not very clever of me.

https://bugs.launchpad.net/qemu/+bug/660366
>> Can someone verify these assumptions for me please?
>> - I can bdrv_open() a file that has a chain of backing files, and the
>> following is true :
>>         - bdrv_read() returns the most recently allocated sector contents (or
>> 0)
> Correct.
>
>>         - bdrv_is_allocated() will return false only if that sector is not
>> allocated in _any_ of the files in the chain
> Incorrect.  It returns true if the sector is allocated in the top-most
> file, false otherwise.  In other words bdrv_is_allocated() is flat, it
> does not traverse a chain of backing files.

Right.

I guess the correct way to do this is to open and traverse all the input and output backing files, 
but I don't see why that should be necessary as the output file is created O_RDWR.

Now as the output file is created with the backing_file option, can I simply bdrv_read() both input 
and output files, and only write to the output file if the sector differs or != 0? Seems like that 
would be the logical way to do everything right while leveraging the complexity of the block 
drivers. It would also allow for maximum "compression" of the output file if the filesystem has all 
unused space wiped (which is my desired usage case).

Brad

  reply	other threads:[~2011-04-27  8:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-27  3:05 [Qemu-devel] Qemu-img convert with -B Brad Campbell
2011-04-27  8:10 ` Stefan Hajnoczi
2011-04-27  8:56   ` Brad Campbell [this message]
2011-04-27 10:06     ` Kevin Wolf
2011-04-27 13:45       ` Brad Campbell
2011-04-27 13:56         ` Kevin Wolf
2011-04-27 14:02           ` Brad Campbell
2011-04-28  2:06             ` Brad Campbell
2011-04-28  6:36               ` Kevin Wolf
2011-04-28  9:38                 ` Brad Campbell

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=4DB7DA44.4030008@fnarfbargle.com \
    --to=brad@fnarfbargle.com \
    --cc=lists2009@fnarfbargle.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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).