1 files changed, 78 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/806 b/results/classifier/zero-shot/108/other/806
new file mode 100644
index 000000000..1b8d1d127
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/806
@@ -0,0 +1,78 @@
+other: 0.937
+permissions: 0.927
+performance: 0.913
+debug: 0.902
+graphic: 0.902
+device: 0.900
+files: 0.893
+socket: 0.887
+semantic: 0.887
+network: 0.867
+PID: 0.855
+vnc: 0.835
+KVM: 0.834
+boot: 0.831
+
+Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts
+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, 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:
+1. 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```
+2. Prepare virtual-disk2
+   Put 85 GiB synthetic generated data sgdata as mentioned in https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694  
+3. Start qemu (command invocation given above)
+4. Partition /dev/sda, put ext4-fs on /dev/sda1
+5. Mount -t ext4 /dev/sda1 /mnt/a 
+6. Mount /dev/sdb2 /mnt/b (mounts using fuse-blk tuxera ntfs driver)
+7. Do rsync: 
+   ```
+   (sdate=`date` ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo $sdate ; date)
+   ```
+8. 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.