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 1730955 - Overlay with compat=0.10 will not be emptied after commitment
Summary: Overlay with compat=0.10 will not be emptied after commitment
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: qemu-kvm
Version: 8.1
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Hanna Czenczek
QA Contact: Tingting Mao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-18 03:05 UTC by Tingting Mao
Modified: 2019-07-27 14:51 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-27 11:47:09 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Tingting Mao 2019-07-18 03:05:54 UTC
Description of problem:
As subject.


Version-Release number of selected component (if applicable):
qemu-kvm-2.12.0-81.module+el8.1.0+3619+dfe1ae01
kernel-4.18.0-112.el8


How reproducible:
100%


Steps to Reproduce:
1. Create a base image
# qemu-img create -f raw test.img 2G

2. Create snapshot with compat=0.10 based on the base image
# qemu-img create -f qcow2 -o compat=0.10 -b test.img sn.qcow2

3. Write data to the snapshot file
# qemu-io -c 'write -P 1 0 512M' sn.qcow2

4. Check info of the images
]# qemu-img info sn.qcow2 --backing-chain
image: sn.qcow2
file format: qcow2
virtual size: 2.0G (2147483648 bytes)
disk size: 512M
cluster_size: 65536
backing file: test.img
Format specific information:
    compat: 0.10
    refcount bits: 16

image: test.img
file format: raw
virtual size: 2.0G (2147483648 bytes)
disk size: 0

5. Commit the snapshot file
# qemu-img commit -f qcow2 sn.qcow2 -p
    (100.00/100%)
Image committed.

6. Check the info of the images again
# qemu-img info sn.qcow2 --backing-chain
image: sn.qcow2
file format: qcow2
virtual size: 2.0G (2147483648 bytes)
disk size: 512M ------------------------------- Not emptied!
cluster_size: 65536
backing file: test.img
Format specific information:
    compat: 0.10
    refcount bits: 16

image: test.img
file format: raw
virtual size: 2.0G (2147483648 bytes)
disk size: 512M


Actual results:
As above. The overlay has not been emptied.


Expected results:
The overlay was emptied.


Additional info:

Comment 1 Tingting Mao 2019-07-18 03:26:13 UTC
In RHEL7.7, there is no the bug, so I mark 'regression', and set priority as 'high'.


Tested with:
qemu-kvm-rhev-2.12.0-30.el7


Steps:
# qemu-img create -f raw test.img 1g

# qemu-img create -f qcow2 -b test.img sn.qcow2 -o compat=0.10

# qemu-io -c 'write -P 1 0 512m' sn.qcow2

# qemu-img info sn.qcow2 --backing-chain
image: sn.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 512M
cluster_size: 65536
backing file: test.img
Format specific information:
    compat: 0.10
    refcount bits: 16

image: test.img
file format: raw
virtual size: 1.0G (1073741824 bytes)
disk size: 0

# qemu-img commit -f qcow2 sn.qcow2 -p

# qemu-img info sn.qcow2 --backing-chain
image: sn.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 324K ------------------------------------- Emptied!
cluster_size: 65536
backing file: test.img
Format specific information:
    compat: 0.10
    refcount bits: 16

image: test.img
file format: raw
virtual size: 1.0G (1073741824 bytes)
disk size: 512M

Comment 3 Ademar Reis 2019-07-26 20:23:55 UTC
Low priority because of compat=0.10 and being a corner-case.

If not a low-hanging fruit, I recommend closing it.

Comment 4 Hanna Czenczek 2019-07-27 11:47:09 UTC
Hi,

qemu supports a fast path for emptying compat=1.1 images (with certain restrictions), and a slow path for all other images.  Only the fast path is sure to reduce the image to a minimal size.  The slow path just discards all active clusters, which may or may not have an immediate, measurable effect.

I don’t know what changed in RHEL 8 when compared to 7.7, but I don’t think it was anything in qemu.  As far as I can see from adding some debug output, we still discard all clusters in an compat=0.10 image, it just somehow doesn’t have an effect on the host.

(If I test RHEL 8’s qemu-img on a Fedora 30 host, I actually don’t see the problem.  The compat=0.10 overlay was emptied during the commit.  I tested upstream before, and I saw the issue, kind of.  The disk usage was reduced by a bit, but not by much.  If I test upstream now, the issue has disappeared.  So maybe it has something to do whether the filesystem feels like actually freeing the blocks immediately.  I suppose it could be due to XFS’s speculative preallocation, so it keeps some blocks allocated to the file and will free them only once it sees the need to.)

Closing the bug, because it looks to me like qemu still discards all blocks, as it should; I suppose the filesystem just doesn’t respond to it visibly immediately.  Please reopen the bug if your filesystem is not XFS.

Max

Comment 5 Tingting Mao 2019-07-27 14:51:43 UTC
I can not reproduce this bug in the latest qemu package even with XFS, either. 


Tested with:
qemu-kvm-2.12.0-82.module+el8.1.0+3738+0d8c0249
4.18.0-112.el8.x86_64
# df -T sn.qcow2 
Filesystem                             Type 1K-blocks      Used Available Use% Mounted on
/dev/mapper/rhel_hp--dl388pg8--01-home xfs  222836224 120377864 102458360  55% /home


Steps:
# qemu-img create -f raw test.img 2G

# qemu-img create -f qcow2 -o compat=0.10 -b test.img sn.qcow2

# qemu-io -c 'write -P 1 0 512M' sn.qcow2

# qemu-img info sn.qcow2 --backing-chain
image: sn.qcow2
file format: qcow2
virtual size: 2.0G (2147483648 bytes)
disk size: 512M
cluster_size: 65536
backing file: test.img
Format specific information:
    compat: 0.10
    refcount bits: 16

image: test.img
file format: raw
virtual size: 2.0G (2147483648 bytes)
disk size: 0

# qemu-img commit -f qcow2 sn.qcow2 -p
    (100.00/100%)
Image committed.

# qemu-img info sn.qcow2 --backing-chain
image: sn.qcow2
file format: qcow2
virtual size: 2.0G (2147483648 bytes)
disk size: 452K    --------------- Emptied !
cluster_size: 65536
backing file: test.img
Format specific information:
    compat: 0.10
    refcount bits: 16

image: test.img
file format: raw
virtual size: 2.0G (2147483648 bytes)
disk size: 512M


Note You need to log in before you can comment on or make changes to this bug.