1 files changed, 0 insertions, 63 deletions
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/806 b/gitlab/issues_text/target_missing/host_missing/accel_missing/806
deleted file mode 100644
index da512a822..000000000
--- a/gitlab/issues_text/target_missing/host_missing/accel_missing/806
+++ /dev/null
@@ -1,63 +0,0 @@
-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.