qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [BUG] qemu-1.1.2 [FIXED-BY] qcow2: Fix avail_sectors in


From: Kevin Wolf
Subject: Re: [Qemu-devel] [BUG] qemu-1.1.2 [FIXED-BY] qcow2: Fix avail_sectors in cluster allocation code
Date: Wed, 12 Dec 2012 17:54:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

Am 12.12.2012 15:09, schrieb Philipp Hahn:
> Hello Kevin, 
> 
> Am Mittwoch 12 Dezember 2012 14:41:49 schrieb Kevin Wolf:
>> As you can see in the commit message of that patch I was convinced that
>> no bug did exist in practice and this was only dangerous with respect to
>> future changes. Therefore my first question is if you're using an
>> unmodified upstream qemu or if some backported patches are applied to
>> it? If it's indeed unmodified, we should probably review the code once
>> again to understand why it makes a difference.
> 
> This were all unmodified versions directly from git between "qemu-kvm-1.1.0" 
> and "qemu-kvm-1.2.0"
> 
> "git checkout b7ab0fea37c15ca9e249c42c46f5c48fd1a0943c" works,
> "git checkout b7ab0fea37c15ca9e249c42c46f5c48fd1a0943c~1" is broken.
> "git checkout qemu-kvm-1.1.2"  is broken,
> "git checkout qemu-kvm-1.1.2 ; git cherry-pick 
> b7ab0fea37c15ca9e249c42c46f5c48fd1a0943c"  works

Ok, thanks for clarifying. Then I must have missed some interesting case
while doing the patch.

Ideally we would find a sequence of qemu-io commands to reliably
reproduce this. First thing worth trying would be running the current
qemu-iotests suite on the old versions. If we don't find it this way, I
guess we need to catch it with code review. I'm not sure if I can get to
it this week, and starting next week I'll be on vacation, so any help
with finding a reproducer would be appreciated.

>> In any case, this is the cluster allocation code. It's probably not
>> related to rereading things from disk, but rather to the writeout of the
>> page cache.
> 
> Yes, the problem is probably write related. But as the write "doens't explode 
> with some spectacular error", I only notice the error on the following read 
> by comparing md5 sums.
> I just re-checked it: After a reboot the md5sums are still invalid, so I 
> guess 
> the data is corrupted on writeout.

Yes, it's really the only thing that makes sense in connection with this
patch.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]