Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1609155

Summary: virt-sparsify failed to sparsify free space with "file" as temporary space on ppc64le
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Xianghua Chen <xchen>
Component: libguestfsAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED WORKSFORME QA Contact: YongkuiGuo <yoguo>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: jsuchane, linl, ptoscano, rjones, yoguo
Target Milestone: rc   
Target Release: 8.1   
Hardware: ppc64le   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-04 06:42:48 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:
Attachments:
Description Flags
log.virt-spasify.file none

Description Xianghua Chen 2018-07-27 07:26:05 UTC
Created attachment 1471004 [details]
log.virt-spasify.file

Description of problem:
virt-sparsify failed to sparsify free space with "file" as temporary space on ppc64le

Version-Release number of selected component (if applicable):
libguestfs-1.38.2-8.el7.ppc64le
kernel-3.10.0-924.el7.ppc64le

How reproducible:
100%

Steps:
1. Create files to be used:
# qemu-img create -f raw virt_tools.ext4.raw 200M
# guestfish -a virt_tools.ext4.raw run : pvcreate "/dev/sda" : vgcreate "vol_test" "/dev/sda" : lvcreate "vol_file" "vol_test" 190 : mkfs "ext4" "/dev/vol_test/vol_file" : vfs_type "/dev/vol_test/vol_file" 
# dd if=/dev/zero of=upload.data bs=1M count=100
# qemu-img create -f qcow2 -b virt_tools.ext4.raw disk_back.qcow2
# ls -s virt_tools.ext4.raw |awk '{print $1}'
5120

2. Upload upload.data to image and delete it and check the size of the image:
#  guestfish -a  virt_tools.ext4.raw run : mount /dev/vol_test/vol_file / : upload  upload.data /upload.data : rm /upload.data
# ls -s virt_tools.ext4.raw |awk '{print $1}'
46312

3. Virt-sparsify using file as tmporary space:
# virt-sparsify virt_tools.ext4.raw /var/run/guestfs-autotest/images/image2 --tmp prebuiltisk_back.qcow2
[   0.1] Using prebuilt file disk_back.qcow2 as overlay
[   0.1] Examine source disk
[   5.6] Fill free space in /dev/vol_test/vol_file with zero
[   8.1] Fill free space in volgroup vol_test with zero
[   8.8] Copy to destination and make sparse
[   8.9] Sparsify operation completed with no errors.
virt-sparsify: Before deleting the old disk, carefully check that the 
target disk boots and works correctly.

# ls -s /var/run/guestfs-autotest/images/image2
186176 /var/run/guestfs-autotest/images/image2


186176>46312 , so failed to sparsify free space. 
Please check attachment for detailed log.

Actual results:
The size after sparsify is bigger than the size in step2.

Expected results:
The size after sparsify should be smaller than the size in step2.

Additional info:
Use dir as temporary space is ok.

Comment 1 Richard W.M. Jones 2018-08-09 06:59:13 UTC
Note there's a typo in step 3.

# virt-sparsify virt_tools.ext4.raw /var/run/guestfs-autotest/images/image2 --tmp prebuiltisk_back.qcow2

should be:

# virt-sparsify virt_tools.ext4.raw /var/run/guestfs-autotest/images/image2 --tmp prebuilt:disk_back.qcow2

Comment 2 Richard W.M. Jones 2018-08-09 07:03:51 UTC
The main difference between x86_64 and ppc64le is the large
page size (4K vs 64K) and I suspect this is the most likely
problem here.  However I will really need to test this on a
ppc64le machine to see what's going on.

Comment 4 YongkuiGuo 2019-06-26 06:19:27 UTC
Can 'not' reproduce this issue on latest rhel8.1.0 compose(RHEL-8.1.0-20190619.2) with the libguestfs-1.38.4-12.module+el8.1.0+3306+18be956d.ppc64le package. I also tested it on rhel7.7 env(a ppc64le vm) and there is no problem. So this issue has disappeared. We can close this bug. 
BTW, I am not sure whether it's rational to change the bug version from 7.6 to 8.0. The most common is to clone this bug from rhel7 to rhel8. If this bug on rhel7 is not fixed, we can close it.