Bug 861425
Summary: | qemu-img should discard empty blocks on block devices | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Neil Wilson <neil> |
Component: | qemu-kvm-rhev | Assignee: | Kevin Wolf <kwolf> |
Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.0 | CC: | areis, huding, jen, juzhang, kwolf, mkenneth, mzhan, neil, rbalakri, rpacheco, virt-maint |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-08-31 08:36:01 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Neil Wilson
2012-09-28 15:09:23 UTC
You get the same effect using '-O raw' on the qemu-img command line. There is an incomplete patch on the Qemu mailing list to implement BLKDISCARD support on host devices: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01659.html Note this requires a kernel with dm-thin discard support enabled. Neil: Thanks for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, we're not able to guarantee the timeliness or suitability of a resolution for issues entered here because this is not a mechanism for requesting support. If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization to assure a timely resolution. For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto We'll target a fix upstream, which will probably be included in RHEL7. I believe this works since upstream qemu 2.0 if the option '-t none' is used for 'qemu-img convert'. The next rebase will take care of it then. It looks as if the BLKDISCARD ioctl doesn't work reliably without O_DIRECT, so we can't use it for other cache modes. Neil, can you please try with a current upstream qemu if it behaves as you intended when you reported this? I test qemu-img-rhev-2.1.0-1.el7.x86_64 using the steps of comment 4. Before run "qemu-img convert", 1. check the raw image, virtual size is 10G and disk size is 2.5G: # qemu-img info test.img image: test.img file format: raw virtual size: 10G (10737418240 bytes) disk size: 2.5G # ls -lsh test.img 2.6G -rw-r--r--. 1 root root 10G Aug 13 10:10 test.img 2. check the thinly provisioned LVM partition, Origin Data% is 0.00 # lvs LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert home rhel_dhcp-8-248 -wi-ao---- 407.50g root rhel_dhcp-8-248 -wi-ao---- 50.00g swap rhel_dhcp-8-248 -wi-ao---- 7.77g mysql_thin servers twi-a-tz-- 30.00g 0.00 srv-msql3-vol servers Vwi-a-tz-- 30.00g mysql_thin 0.00 3. copy the image to the thinly provisioned LVM partition with "-t none"] # qemu-img convert -p test.img -O raw -t none /dev/servers/srv-msql3-vol (100.00/100%) 4. check the thinly provisioned LVM partition # lvs LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert home rhel_dhcp-8-248 -wi-ao---- 407.50g root rhel_dhcp-8-248 -wi-ao---- 50.00g swap rhel_dhcp-8-248 -wi-ao---- 7.77g mysql_thin servers twi-a-tz-- 30.00g 33.33 srv-msql3-vol servers Vwi-a-tz-- 30.00g mysql_thin 33.33 after step4, the Origin Data% is 33.3% of a 30G thin pool, it is about 10G, but it should be about 2.5G. Based on the result of comment 11, I modify the status to "ASSIGNED". If I was wrong, please fix me. Comment 9 suggests that the problem was fixed in upstream QEMU 2.0, but testing results in comment 11 reports that the problem still exists. Meanwhile, rebasing to QEMU 2.0 has occurred, so the value in Fixed In Version is no longer relevant. Therefore, I'm clearing the Fixed In Version field. Please let me know if you have any questions. I tried to reproduce the failure on a current QEMU version, and I could indeed see that the full space was taken. On a closer look I saw that QEMU issued a BLKDISCARDZEROES ioctl, i.e. it asked the kernel whether the device supported zeroing data with BLKDISCARD, and the answer was no. So that's why it had to write all of the data explicitly. I'm not sure what needs to be done so that a thin LV actually advertises that it supports this (if it's possible at all), but can you please check "blockdev --getdiscardzeroes" for your LV to see if that's the same problem for you? If so, then this isn't a QEMU problem because QEMU can only make use of BLKDISCARD if that guarantees to zero out the image. Almost four weeks without an answer and the 7.3 cycle is nearing its end, so I'll just assume that my suspicion is right and close the bug. If you eventually find out that your scenario is different, please reopen. |