qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] why marking qcow2 img as corrupted


From: Eric Blake
Subject: Re: [Qemu-devel] why marking qcow2 img as corrupted
Date: Thu, 27 Jul 2017 07:44:24 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 07/26/2017 10:53 PM, lampahome wrote:
> I tried take snapshots on a demo.qcow2 10 times.
> cmd is below:
> 
>> qemu-img snapshots -c tag_1 demo.qcow2

Which version of qemu-img?  Also, can you show 'qemu-img info
demo.qcow2'? Is your guest running at the same time, or is qemu-img the
only process touching the file?

If you were using something older than qemu 2.9 (where we enabled image
locking protection), then I suspect what happened is that you corrupted
your image because you had multiple writer processes acting on the file
at once.  If so, your image really is corrupted, and I hope you have a
good backup.  qemu stopped making the damage worse, but recovering data
from a corrupted image is not always possible.  (Even with newer qemu,
you can still override multiple writer protection, but you really
shouldn't, as it is really there for your protection.)

You are creating internal snapshots, which don't get quite as much
testing, but you SHOULD be able to create multiple internal snapshots in
a row (certainly more than 7) without it causing internal corruption
(there is a finite limit based on your choice of refcount_order in the
qcow2 header; the default order of 4 permits up to nearly 64k snapshots,
while setting the order to 0 prohibits snapshots - but you should get a
sane error message about exceeding limits, rather than image corruption).

Also, see if you can adjust your workflow to use external snapshots
instead of internal, to avoid running into the issue.

> 
> 
> when I take snapshots 7 times and console shows:
> 
>> mark image as corrupted and preventing from invalid write
> 
> 
> and I can't take snapshots anymore then.
> Can I avoid this situation or remove the limit?

At any rate, I couldn't reproduce your problem when not violating
multiple writer constraints:

$ ./qemu-img --version
qemu-img version 2.9.90 (v2.10.0-rc0-1-g0f0f0a5335)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
$ ./qemu-img create -f qcow2 example 1M
Formatting 'example', fmt=qcow2 size=1048576 cluster_size=65536
lazy_refcounts=off refcount_bits=16
$ # An empty file is no fun, add some data
$ ./qemu-io -f qcow2 -c 'w 0 64k' example
wrote 65536/65536 bytes at offset 0
64 KiB, 1 ops; 0.0428 sec (1.458 MiB/sec and 23.3236 ops/sec)
$ # Create lots of internal snapshots
$ for i in `seq 16`; do ./qemu-img snapshot -c tag_$i example; done
$ ./qemu-img info example
image: example
file format: qcow2
virtual size: 1.0M (1048576 bytes)
disk size: 396K
cluster_size: 65536
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         tag_1                     0 2017-07-27 07:35:00   00:00:00.000
2         tag_2                     0 2017-07-27 07:35:00   00:00:00.000
3         tag_3                     0 2017-07-27 07:35:00   00:00:00.000
4         tag_4                     0 2017-07-27 07:35:00   00:00:00.000
5         tag_5                     0 2017-07-27 07:35:00   00:00:00.000
6         tag_6                     0 2017-07-27 07:35:01   00:00:00.000
7         tag_7                     0 2017-07-27 07:35:01   00:00:00.000
8         tag_8                     0 2017-07-27 07:35:01   00:00:00.000
9         tag_9                     0 2017-07-27 07:35:01   00:00:00.000
10        tag_10                    0 2017-07-27 07:35:01   00:00:00.000
11        tag_11                    0 2017-07-27 07:35:01   00:00:00.000
12        tag_12                    0 2017-07-27 07:35:01   00:00:00.000
13        tag_13                    0 2017-07-27 07:35:01   00:00:00.000
14        tag_14                    0 2017-07-27 07:35:01   00:00:00.000
15        tag_15                    0 2017-07-27 07:35:01   00:00:00.000
16        tag_16                    0 2017-07-27 07:35:01   00:00:00.000
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

And demonstrating the smaller refcount_order:

$ rm example
$ ./qemu-img create -f qcow2 -o refcount_bits=2 example 1M
Formatting 'example', fmt=qcow2 size=1048576 cluster_size=65536
lazy_refcounts=off refcount_bits=2
$ ./qemu-io -f qcow2 -c 'w 0 64k' example
wrote 65536/65536 bytes at offset 0
64 KiB, 1 ops; 0.0324 sec (1.925 MiB/sec and 30.7967 ops/sec)
$ for i in `seq 3`; do ./qemu-img snapshot -c tag_$i example; done
qemu-img: Could not create snapshot 'tag_3': -22 (Invalid argument)

Not the nicest of error messages ("-22 (Invalid argument)" could
probably be something saner like "refcount_bits exceeded"), but the
image is still not corrupted:

$ qemu-img info example
image: example
file format: qcow2
virtual size: 1.0M (1048576 bytes)
disk size: 344K
cluster_size: 65536
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         tag_1                     0 2017-07-27 07:40:41   00:00:00.000
2         tag_2                     0 2017-07-27 07:40:41   00:00:00.000
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 2
    corrupt: false

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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