qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH 0/2] qcow2: Do not mark inactive images corrupt


From: Max Reitz
Subject: Re: [Qemu-block] [PATCH 0/2] qcow2: Do not mark inactive images corrupt
Date: Wed, 6 Jun 2018 21:32:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 2018-06-04 20:58, John Snow wrote:
> 
> 
> On 06/04/2018 10:14 AM, Max Reitz wrote:
>> The non-public logs in
>> https://bugzilla.redhat.com/show_bug.cgi?id=1583346 (sorry...) reveal
>> this problem:
>>
>> $ (Create a qcow2 file "foo.qcow2" with a corrupted first L1 entry)
>> $ echo 'qemu-io none0 "read 0 512"' \
>>     | x86_64-softmmu/qemu-system-x86_64 -drive if=none,file=foo.qcow2 \
>>                                         -monitor stdio \
>>                                         -incoming exec:'cat /dev/null'
>> QEMU 2.12.50 monitor - type 'help' for more information
>> (qemu) qemu-io none0 "read 0 512"
>> qcow2: Marking image as corrupt: L2 table offset 0x44200 unaligned (L1 
>> index: 0); further corruption events will be suppressed
>> qemu-system-x86_64: block/io.c:1691: bdrv_co_pwritev: Assertion 
>> `!(bs->open_flags & BDRV_O_INACTIVE)' failed.
>> [1]    18444 done                 echo 'qemu-io none0 "read 0 512"' | 
>>        18445 abort (core dumped)  x86_64-softmmu/qemu-system-x86_64 -drive 
>> if=none,file=foo.qcow2 -monitor stdi
>>
>> Oops.
>>
>>
>> The first patch in this series fixes this by treating inactive images
>> like read-only images in this regard (which most importantly means not
>> trying to set the corrupt flag on them), the second one adds an iotest
>> case.
>>
>>
>> Max Reitz (2):
>>   qcow2: Do not mark inactive images corrupt
>>   iotests: Add case for a corrupted inactive image
>>
>>  block/qcow2.c              |  4 +++-
>>  tests/qemu-iotests/060     | 30 ++++++++++++++++++++++++++++++
>>  tests/qemu-iotests/060.out | 14 ++++++++++++++
>>  3 files changed, 47 insertions(+), 1 deletion(-)
>>
> 
> Makes sense to me, provided it's safe to check via BDRV_O_RDWR instead
> of bs->read_only. (I assume it is.)

It's all a mess is all I can say.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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