From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: "Kashyap Chamarthy" <kashyap.cv@gmail.com>,
qemu-devel@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>,
"Benoît Canet" <benoit@irqsave.net>
Subject: Re: [Qemu-devel] [PATCH] qemu-img: Add --backing-chain option to info command
Date: Fri, 12 Oct 2012 08:50:25 -0600 [thread overview]
Message-ID: <50782E31.3080702@redhat.com> (raw)
In-Reply-To: <50782B57.7050208@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]
On 10/12/2012 08:38 AM, Kevin Wolf wrote:
>> Hmm. For 'qemu-img info', I can see two behaviors, both useful, when
>> presented with a corrupt image. One is to error out right away (because
>> qemu would be unable to use the image). But the other is for debugging
>> WHY the image is corrupt, at which point I want qemu-img info to display
>> as much information as possible, INCLUDING what backing file is recorded
>> in the header, so that I can follow the loop and decide where to break
>> the loop. Sounds like we might need another flag to bdrv_open() on
>> whether to detect cycles; as well as fixing qemu-img info to check for
>> cycles on its own when it bypasses normal cycle-checking in bdrv_open.
>
> Makes sense. Though I think BDRV_O_NO_BACKING is enough to implement
> this functionality in qemu-img. We'd just have to have an error code
> that allows qemu-img to check if we detected a loop so that it can start
> searching the broken image.
Indeed - BDRV_O_NO_BACKING seems to be the flag that prevents bdrv_open
from failing on a cycle, so the logic would be something like:
Try a normal bdrv_open()
if it succeeds
image is fine, so recursively print it
else if error indicated a loop
init hash table
while (1)
if file in hash table
break, since we identified the loop
bdrv_open(BDRV_O_NO_BACKING)
print this file, then add it to the hash table
file = backing
At any rate, adding this logic should be a separate patch, and not hold
up Stefan's current patch.
--
Eric Blake eblake@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 617 bytes --]
next prev parent reply other threads:[~2012-10-12 14:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-12 14:09 [Qemu-devel] [PATCH] qemu-img: Add --backing-chain option to info command Stefan Hajnoczi
2012-10-12 14:18 ` Eric Blake
2012-10-12 14:24 ` Eric Blake
2012-10-12 14:27 ` Kevin Wolf
2012-10-12 14:32 ` Eric Blake
2012-10-12 14:38 ` Kevin Wolf
2012-10-12 14:50 ` Eric Blake [this message]
2012-10-12 19:16 ` Kashyap Chamarthy
2012-10-12 20:19 ` Kashyap Chamarthy
2012-10-12 20:31 ` Eric Blake
2012-10-13 15:50 ` Kashyap Chamarthy
2012-10-13 21:36 ` Eric Blake
2012-10-14 6:10 ` Kashyap Chamarthy
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=50782E31.3080702@redhat.com \
--to=eblake@redhat.com \
--cc=benoit@irqsave.net \
--cc=kashyap.cv@gmail.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 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.