qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Toolybird <1850000@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1850000] Re: 4.1.0 bogus QCOW2 corruption reported after compress
Date: Sun, 27 Oct 2019 04:58:31 -0000	[thread overview]
Message-ID: <157215231134.18979.16782302206432118351.malone@wampee.canonical.com> (raw)
In-Reply-To: 157212805514.19102.17568097209992499457.malonedeb@wampee.canonical.com

Current trunk still displays the problem.

A git bisection between 4.0.0 and 4.1.0 revealed:

b6c246942b14d3e0dec46a6c5868ed84e7dbea19 is the first bad commit
commit b6c246942b14d3e0dec46a6c5868ed84e7dbea19
Author: Alberto Garcia <berto@igalia.com>
Date:   Fri May 10 19:22:54 2019 +0300

    qcow2: Define and use QCOW2_COMPRESSED_SECTOR_SIZE
    
    When an L2 table entry points to a compressed cluster the space used
    by the data is specified in 512-byte sectors. This size is independent
    from BDRV_SECTOR_SIZE and is specific to the qcow2 file format.
    
    The QCOW2_COMPRESSED_SECTOR_SIZE constant defined in this patch makes
    this explicit.
    
    Signed-off-by: Alberto Garcia <berto@igalia.com>
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>

 block/qcow2-cluster.c  |  5 +++--
 block/qcow2-refcount.c | 25 ++++++++++++++-----------
 block/qcow2.c          |  3 ++-
 block/qcow2.h          |  4 ++++
 4 files changed, 23 insertions(+), 14 deletions(-)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1850000

Title:
  4.1.0 bogus QCOW2 corruption reported after compress

Status in QEMU:
  New

Bug description:
  Creating a compressed image then running `qemu-img check <..>.qcow2'
  on said image seems to report bogus corruption in some (but not all)
  cases:

  Step 1.

  # qemu-img info win7-base.qcow2
  image: win7-base.qcow2
  file format: qcow2
  virtual size: 20 GiB (21474836480 bytes)
  disk size: 12.2 GiB
  cluster_size: 65536
  Format specific information:
      compat: 1.1
      lazy refcounts: true
      refcount bits: 16
      corrupt: false

  # qemu-img check win7-base.qcow2
  No errors were found on the image.
  327680/327680 = 100.00% allocated, 0.00% fragmented, 0.00% compressed clusters
  Image end offset: 21478375424

  Step 2.

  # qemu-img convert -f qcow2 -O qcow2 -c win7-base.qcow2 test1-z.qcow2

  Step 3.

  # qemu-img info test1-z.qcow2
  image: test1-z.qcow2
  file format: qcow2
  virtual size: 20 GiB (21474836480 bytes)
  disk size: 5.78 GiB
  cluster_size: 65536
  Format specific information:
      compat: 1.1
      lazy refcounts: false
      refcount bits: 16
      corrupt: false

  # qemu-img check test1-z.qcow2
  ERROR cluster 1191 refcount=1 reference=2
  ERROR cluster 1194 refcount=1 reference=4
  ERROR cluster 1195 refcount=1 reference=7
  ERROR cluster 1196 refcount=1 reference=7
  ERROR cluster 1197 refcount=1 reference=6
  ERROR cluster 1198 refcount=1 reference=4
  ERROR cluster 1199 refcount=1 reference=4
  ERROR cluster 1200 refcount=1 reference=5
  ERROR cluster 1201 refcount=1 reference=3
  <...> snip many errors
  Leaked cluster 94847 refcount=3 reference=0
  Leaked cluster 94848 refcount=3 reference=0
  Leaked cluster 94849 refcount=11 reference=0
  Leaked cluster 94850 refcount=14 reference=0

  20503 errors were found on the image.
  Data may be corrupted, or further writes to the image may corrupt it.

  20503 leaked clusters were found on the image.
  This means waste of disk space, but no harm to data.
  197000/327680 = 60.12% allocated, 89.32% fragmented, 88.50% compressed clusters
  Image end offset: 6216220672

  
  The resultant image seems to work fine in a VM when used as a backing file.

  Interestingly, if I substitute a qemu-img binary from qemu-4.0 then no
  errors are reported.

  # /tmp/qemu-img check test1-z.qcow2
  No errors were found on the image.
  197000/327680 = 60.12% allocated, 89.32% fragmented, 88.50% compressed clusters
  Image end offset: 6216220672

  Is the image corrupted or not? I'm guessing not.

  Just in case it matters, this is ext4 fs on rotational disk. Latest
  Arch Linux but self compiled 4.1.0 with recent QCOW2 corruption fixes
  added.

  I haven't tried latest trunk but might do so if time permits.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1850000/+subscriptions


  reply	other threads:[~2019-10-27  5:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-26 22:14 [Bug 1850000] [NEW] 4.1.0 bogus QCOW2 corruption reported after compress Toolybird
2019-10-27  4:58 ` Toolybird [this message]
2019-10-28 15:18 ` [Bug 1850000] " Max Reitz
2019-10-30 11:23 ` Max Reitz
2019-10-30 23:18 ` Toolybird
2020-01-09 17:24 ` Thomas Huth

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=157215231134.18979.16782302206432118351.malone@wampee.canonical.com \
    --to=1850000@bugs.launchpad.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).