From: Eric Blake <eblake@redhat.com>
To: Guannan Ren <gren@redhat.com>
Cc: libvir-list@redhat.com, Jeff Cody <jcody@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [libvirt] [PATCH] snapshot: fix rollback failure in transaction mode
Date: Wed, 12 Sep 2012 11:47:36 -0600 [thread overview]
Message-ID: <5050CAB8.6040702@redhat.com> (raw)
In-Reply-To: <1347463350-28760-1-git-send-email-gren@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]
On 09/12/2012 09:22 AM, Guannan Ren wrote:
> After failure of qemu transaction command, the snapshot file still
> be there with non-zero in size. In order to unlink the file, the
> patch removes the file size checking.
Can you give some exact steps to reproduce this, so that I know who is
making the file have non-zero size? I'm worried that unlinking a
non-empty file is discarding data, so the commit message needs a lot
more details about how we are proving that the only way the file can be
non-zero size is because qemu happened to put data into a previously
empty file prior to the failed 'transaction' attempt.
That is, after re-reading context code just now, I'm fairly confident
that this code can only be reached when qemu supports the 'transaction'
monitor command, and libvirt's --reuse-ext flag was not specified, and
therefore libvirt must have just created the file. But I want that in
the commit message rather than having to re-read the code every time I
visit this commit in future reads of the git log. It may also be that
qemu has a bug in that the 'transaction' command is modifying files even
when it fails, so even while this works around the bug, I'm cc'ing Jeff
to see if qemu also needs a bug fix.
> ---
> src/qemu/qemu_driver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 8e8e00c..1fedfb8 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -10833,7 +10833,7 @@ qemuDomainSnapshotUndoSingleDiskActive(struct qemud_driver *driver,
> if (virDomainLockDiskDetach(driver->lockManager, vm, disk) < 0)
> VIR_WARN("Unable to release lock on %s", disk->src);
> if (need_unlink && stat(disk->src, &st) == 0 &&
> - st.st_size == 0 && S_ISREG(st.st_mode) && unlink(disk->src) < 0)
> + S_ISREG(st.st_mode) && unlink(disk->src) < 0)
> VIR_WARN("Unable to remove just-created %s", disk->src);
>
> /* Update vm in place to match changes. */
>
--
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 parent reply other threads:[~2012-09-12 17:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1347463350-28760-1-git-send-email-gren@redhat.com>
2012-09-12 17:47 ` Eric Blake [this message]
2012-09-12 18:33 ` [Qemu-devel] [libvirt] [PATCH] snapshot: fix rollback failure in transaction mode Jeff Cody
2012-09-12 20:23 ` Eric Blake
2012-09-13 3:16 ` Guannan Ren
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=5050CAB8.6040702@redhat.com \
--to=eblake@redhat.com \
--cc=gren@redhat.com \
--cc=jcody@redhat.com \
--cc=libvir-list@redhat.com \
--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.