Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts
Host environment
- Operating system:
Linux/Fedora 35
and alsoWindows-10
- OS/kernel version:
Linux sirius 5.10.90-200.fc35.x86_64 #1 SMP Thu Jan 6 16:22:52 IST 2022 x86_64 x86_64 x86_64 GNU/Linux
self built using rpmbuild using srcrpm template kernel-5.10.23-200.fc33.src.rpm from koji https://koji.fedoraproject.org/koji/packageinfo?packageID=8 - QEMU flavor:
qemu-system-x86_64
- QEMU version:
QEMU emulator version 6.2.0 (qemu-6.1.0-1.fc36)
installed from koji https://koji.fedoraproject.org/koji/packageinfo?packageID=3685 - QEMU command line:
[root@sirius gana]# qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot "d" -cdrom "/vol/15KJ_Images/transcend/Fedora-Workstation-Live-x86_64-Rawhide-20220106.n.0.iso" -hda "/mnt/a16/gkpics01.vhdx" -hdb "/vol/15KJ_Images/test/sgdata.vhdx" -device "virtio-vga" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15"
- Architecture: x86_64
Emulated/Virtualized environment
- (guest OS does not matter)
- Operating system: Fedora 35+ (Fedora-Workstation-Live-x86_64-Rawhide-20220106.n.0.iso)
- OS/kernel version: 5.15+
Linux localhost-live 5.16.0-0.rc8.55.fc36.x86_64 #1 SMP PREEMPT Mon Jan 3 16:35:18 UTC 2022 x86_64 x86_64 GNU/Linux
- Architecture:
x86_64
Description of problem
Fixed VHDX inflates beyond its fixed size when data is copied onto it Possibly also corrupted
Filing this bug as separate from #727 (closed), that issue is for corruption during expansion of a dynamic disk. The effect seen here is different. There may or may not be a chance of common cause. New blocks should not have to be allocated to the VHDX spec Block-Allocation-Table (BAT), there may be a simpler and different fix for this issue.
Perhaps blocks are written to a VHDX journal without being committed to allocated blocks. Perhaps the host's ExFAT filesystem, does not allow reclaiming the blocks that are to be replaced by punching holes and so must be over-written instead of punching holes.
Steps to reproduce
- Prepare virtual-disk1
Create fixed vhdx
[root@sirius gana]# qemu-img create -f vhdx /mnt/a16/gkpics01.vhdx -o subformat=fixed 99723771904 Formatting '/mnt/a16/gkpics01.vhdx', fmt=vhdx size=99723771904 log_size=1048576block_size=0 subformat=fixed```
- Prepare virtual-disk2 Put 85 GiB synthetic generated data sgdata as mentioned in #727 (comment 739930694)
- Start qemu (command invocation given above)
- Partition /dev/sda, put ext4-fs on /dev/sda1
- Mount -t ext4 /dev/sda1 /mnt/a
- Mount /dev/sdb2 /mnt/b (mounts using fuse-blk tuxera ntfs driver)
- Do rsync:
(sdate=`date` ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo $sdate ; date)
- In a host terminal, do ls -l on the vhdx file, and observe that it grows in size (see logs below)
Additional information
- virtual-disk-1 (<90 GiB) is on ExFAT partition (150 GiB) on SSD
- virtual-disk-2 (~85 Gib) is on NTFS3 partition (1 TiB) on HDD
[root@sirius gana]# qemu-img create -f vhdx /mnt/a16/gkpics01.vhdx -o subformat=fixed 99723771904
Formatting '/mnt/a16/gkpics01.vhdx', fmt=vhdx size=99723771904 log_size=1048576block_size=0 subformat=fixed
[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
-rwxr-xr-x. 1 root root 99732160512 Jan 8 13:11 /mnt/a16/gkpics01.vhdx
[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
-rwxr-xr-x. 1 root root 99732160512 Jan 8 13:11 /mnt/a16/gkpics01.vhdx
[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
-rwxr-xr-x. 1 root root 99732160512 Jan 8 13:11 /mnt/a16/gkpics01.vhdx
[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
-rwxr-xr-x. 1 root root 99765714944 Jan 8 13:35 /mnt/a16/gkpics01.vhdx
[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
do gdisk and partition in guestvm
-rwxr-xr-x. 1 root root 100705239040 Jan 8 13:36 /mnt/a16/gkpics01.vhdx
do mkfs -t ext4 in guestvm
[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
-rwxr-xr-x. 1 root root 101342773248 Jan 8 13:36 /mnt/a16/gkpics01.vhdx
start rsyncing data in guestvm
[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
-rwxr-xr-x. 1 root root 102097747968 Jan 8 13:38 /mnt/a16/gkpics01.vhdx
[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
-rwxr-xr-x. 1 root root 102215188480 Jan 8 13:38 /mnt/a16/gkpics01.vhdx
[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
-rwxr-xr-x. 1 root root 149375942656 Jan 8 13:50 /mnt/a16/gkpics01.vhdx
[root@sirius gana]# ls -l /mnt/a16/gkpics01.vhdx
-rwxr-xr-x. 1 root root 156170715136 Jan 8 13:58 /mnt/a16/gkpics01.vhdx
in my case partition fills up and not completed.
Expected Behavior
The fixed VHDX file size should not change/grow. Blocks that are already allocated should be re-used and written-to.
Actual Behavior
The fixed VHDX file size grows. New blocks are allocated.
tests
- Inflation and Corruption does happen on kernel-5.15.0-60/qemu-nbd-6.1.0-10/ExFAT/vhdx(fixed)/ntfs3
- Inflation and Corruption does happen on kernel-5.10.90-200/VM-qemu-6.2.0-0/alpine-standard-3.15.0-x86_64.iso/kernel-5.15.4/vhdx(fixed)/ntfs3
- Inflation and Corruption does happen on kernel-5.10.90-200/VM-qemu-6.2.0-0/archlinux-2022.01.01-x86_64.iso/kernel-5.15.12/vhdx(fixed)/ntfs3
- Inflation and Corruption does happen on Win10-21H2-19044-1415/WHPX/ExFAT/VM-qemu-6.2.0/alpine-standard-3.15.0-x86_64.iso/kernel-5.15.4/vhdx(fixed)/ext4 with sgdata on ntfs-fuseblk/vhdx.
qemu cmd:C:\vol\scoop_01\scoopg\shims\qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35,kernel-irqchip=off" -accel whpx -smp "sockets=1,cores=8,threads=1" -boot d -cdrom E:\transcend\alpine-standard-3.15.0-x86_64.iso -hda H:\gkpics01.vhdx -hdb E:\test\sgdata.vhdx -display gtk -vga virtio -rtc base=utc -netdev user,id=vmnic1,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15 -device virtio-net,netdev=vmnic1
rsync cmd:rsync -avH ./photos001 --include='photos001' --include='photos001/D000*' --include='photos001/D001*' --include='photos001/D000*/***' --include='photos001/D001*/***' --exlcude='*' /mnt/a
to copy under 41GiB to ensure expanded fixed VHDX is does not fill the 150Gib ExFAT drive. I then truncated the find.CHECKSUM file to only those files. The corruption shows even before unmounting - Inflation and Corruption, both do not happen on Win10-21H2-19044-1415/WHPX/ExFAT/VM-qemu-6.2.0/alpine-standard-3.15.0-x86_64.iso/kernel-5.15.4/raw/ext4 with sgdata on ntfs-fuseblk/vhdx.
create raw file with chrysocome windd:C:\vol\prog_01\prog\windd_chrysocome\ddrelease64.exe bs=1048576 count=95104 if=/dev/zero of=H:/gkpics01.raw --progress
- Inflation and Corruption, both do not happen on Win10-21H2-19044-1415/WHPX/ExFAT/VM-qemu-6.2.0/Fedora-Workstation-Live-x86_64-Rawhide-20220111.n.1.iso/kernel-5.16.0-60/raw/ext4 with sgdata on ntfs-fuseblk/vhdx.
- Inflation and Corruption, both do not happen on Win10-21H2-19044-1415/WHPX/ExFAT/VM-qemu-6.2.0/Fedora-Workstation-Live-x86_64-Rawhide-20220111.n.1.iso/kernel-5.16.0-60/raw/ext4 with sgdata on ntfs3/vhdx.