diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-05-21 21:21:26 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-05-21 21:21:26 +0200 |
| commit | 4b927bc37359dec23f67d3427fc982945f24f404 (patch) | |
| tree | 245449ef9146942dc7fffd0235b48b7e70a00bf2 /gitlab/issues/target_missing/host_missing/accel_missing/806.toml | |
| parent | aa8bd79cec7bf6790ddb01d156c2ef2201abbaab (diff) | |
| download | qemu-analysis-4b927bc37359dec23f67d3427fc982945f24f404.tar.gz qemu-analysis-4b927bc37359dec23f67d3427fc982945f24f404.zip | |
add gitlab issues in toml format
Diffstat (limited to 'gitlab/issues/target_missing/host_missing/accel_missing/806.toml')
| -rw-r--r-- | gitlab/issues/target_missing/host_missing/accel_missing/806.toml | 71 |
1 files changed, 71 insertions, 0 deletions
diff --git a/gitlab/issues/target_missing/host_missing/accel_missing/806.toml b/gitlab/issues/target_missing/host_missing/accel_missing/806.toml new file mode 100644 index 000000000..2f917329a --- /dev/null +++ b/gitlab/issues/target_missing/host_missing/accel_missing/806.toml @@ -0,0 +1,71 @@ +id = 806 +title = "Fixed VHDX inflates beyond its fixed size when data is copied onto it and also corrupts" +state = "opened" +created_at = "2022-01-08T08:39:35.065Z" +closed_at = "n/a" +labels = ["Storage"] +url = "https://gitlab.com/qemu-project/qemu/-/issues/806" +host-os = "``Linux/Fedora 35``` and also ```Windows-10``" +host-arch = "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" +guest-os = "Fedora 35+ (Fedora-Workstation-Live-x86_64-Rawhide-20220106.n.0.iso)" +guest-arch = "``x86_64``" +description = """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.""" +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 = """* 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.""" |