blob: fa99f345fcfe7bef6b5323a9632b3cb46ae40803 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
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.
|