RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1527122 - The copied flag should be updated during '-r leaks'
Summary: The copied flag should be updated during '-r leaks'
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.5
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Hanna Czenczek
QA Contact: Tingting Mao
URL:
Whiteboard:
Depends On: 1527085
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-18 15:31 UTC by Ping Li
Modified: 2018-10-30 10:38 UTC (History)
8 users (show)

Fixed In Version: qemu-kvm-1.5.3-158.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1527085
Environment:
Last Closed: 2018-10-30 10:38:18 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Comment 4 Miroslav Rezanina 2018-06-27 06:33:11 UTC 
Fix included in qemu-kvm-1.5.3-158.el7
Comment 6 Ping Li 2018-06-27 07:48:15 UTC 
Verified the issue with below packages and test steps.

Packages tested:
kernel-3.10.0-915.el7
qemu-kvm-1.5.3-158.el7

Test steps:
1. Create image and write data into the image
# qemu-img create -f qcow2 base.qcow2 100M
# qemu-io -c "write 0 1M" base.qcow2

2. Create internal snapshot
# qemu-img snapshot -c sn base.qcow2

3. Delete internal snapshot through blkdebug
# cat >> blkdebug.cfg << eof
[inject-error]
event = "cluster_free"
errno = "28"
immediately = "off"
eof
# qemu-img snapshot -d sn blkdebug:blkdebug.cfg:base.qcow2 
qcow2_free_clusters failed: No space left on device
qemu-img: Could not delete snapshot 'sn': -28 (No space left on device)

4. Check the image
# qemu-img check base.qcow2
Leaked cluster 4 refcount=2 reference=1
Leaked cluster 5 refcount=2 reference=1
Leaked cluster 6 refcount=2 reference=1
Leaked cluster 7 refcount=2 reference=1
Leaked cluster 8 refcount=2 reference=1
Leaked cluster 9 refcount=2 reference=1
Leaked cluster 10 refcount=2 reference=1
Leaked cluster 11 refcount=2 reference=1
Leaked cluster 12 refcount=2 reference=1
Leaked cluster 13 refcount=2 reference=1
Leaked cluster 14 refcount=2 reference=1
Leaked cluster 15 refcount=2 reference=1
Leaked cluster 16 refcount=2 reference=1
Leaked cluster 17 refcount=2 reference=1
Leaked cluster 18 refcount=2 reference=1
Leaked cluster 19 refcount=2 reference=1
Leaked cluster 20 refcount=2 reference=1
Leaked cluster 21 refcount=1 reference=0
Leaked cluster 22 refcount=1 reference=0

19 leaked clusters were found on the image.
This means waste of disk space, but no harm to data.
16/1600 = 1.00% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 1507328

5. Repair cluster leaks
# qemu-img check -r leaks base.qcow2
Leaked cluster 4 refcount=2 reference=1
Leaked cluster 5 refcount=2 reference=1
Leaked cluster 6 refcount=2 reference=1
Leaked cluster 7 refcount=2 reference=1
Leaked cluster 8 refcount=2 reference=1
Leaked cluster 9 refcount=2 reference=1
Leaked cluster 10 refcount=2 reference=1
Leaked cluster 11 refcount=2 reference=1
Leaked cluster 12 refcount=2 reference=1
Leaked cluster 13 refcount=2 reference=1
Leaked cluster 14 refcount=2 reference=1
Leaked cluster 15 refcount=2 reference=1
Leaked cluster 16 refcount=2 reference=1
Leaked cluster 17 refcount=2 reference=1
Leaked cluster 18 refcount=2 reference=1
Leaked cluster 19 refcount=2 reference=1
Leaked cluster 20 refcount=2 reference=1
Leaked cluster 21 refcount=1 reference=0
Leaked cluster 22 refcount=1 reference=0
Repairing cluster 4 refcount=2 reference=1
Repairing cluster 5 refcount=2 reference=1
Repairing cluster 6 refcount=2 reference=1
Repairing cluster 7 refcount=2 reference=1
Repairing cluster 8 refcount=2 reference=1
Repairing cluster 9 refcount=2 reference=1
Repairing cluster 10 refcount=2 reference=1
Repairing cluster 11 refcount=2 reference=1
Repairing cluster 12 refcount=2 reference=1
Repairing cluster 13 refcount=2 reference=1
Repairing cluster 14 refcount=2 reference=1
Repairing cluster 15 refcount=2 reference=1
Repairing cluster 16 refcount=2 reference=1
Repairing cluster 17 refcount=2 reference=1
Repairing cluster 18 refcount=2 reference=1
Repairing cluster 19 refcount=2 reference=1
Repairing cluster 20 refcount=2 reference=1
Repairing cluster 21 refcount=1 reference=0
Repairing cluster 22 refcount=1 reference=0
Repairing OFLAG_COPIED L2 cluster: l1_index=0 l1_entry=40000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=50000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=60000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=70000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=80000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=90000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=a0000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=b0000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=c0000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=d0000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=e0000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=f0000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=100000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=110000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=120000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=130000 refcount=1
Repairing OFLAG_COPIED data cluster: l2_entry=140000 refcount=1
The following inconsistencies were found and repaired:

    19 leaked clusters
    17 corruptions

Double checking the fixed image now...
No errors were found on the image.
16/1600 = 1.00% allocated, 0.00% fragmented, 0.00% compressed clusters
Image end offset: 1376256

6. Run case 217 in qemu-iotests
# rpm -ivhf qemu-kvm-1.5.3-158.el7.src.rpm
# rpmbuild -bp /root/rpmbuild/SPECS/qemu-kvm.spec --nodeps
# cd /root/rpmbuild/BUILD/qemu-1.5.3/
# export QEMU_PROG=/usr/libexec/qemu-kvm
# cd tests/qemu-iotests
./check -qcow2 217
QEMU          -- /usr/libexec/qemu-kvm
QEMU_IMG      -- /usr/bin/qemu-img
QEMU_IO       -- /usr/bin/qemu-io 
IMGFMT        -- qcow2 (compat=1.1)
IMGPROTO      -- file
PLATFORM      -- Linux/x86_64 hp-dl580g7-03 3.10.0-915.el7.x86_64

217        
Passed all 1 tests
Comment 8 errata-xmlrpc 2018-10-30 10:38:18 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3155
Note You need to log in before you can comment on or make changes to this bug.