What's wrong with ext4 in vhdx?

Question

linux

• /$ df -h
  
• Filesystem Size Used Avail Use% Mounted on
  
• udev 1.9G 0 1.9G 0% /dev
  
• tmpfs 388M 940K 387M 1% /run
  
• /dev/mapper/ubuntu--vg-ubuntu--lv 19G 7.1G 11G 41% /
  
• tmpfs 1.9G 28K 1.9G 1% /dev/shm
  
• tmpfs 5.0M 0 5.0M 0% /run/lock
  
• tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
  
• /dev/loop2 44M 44M 0 100% /snap/snapd/14978
  
• /dev/loop0 62M 62M 0 100% /snap/core20/1328
  
• /dev/loop1 68M 68M 0 100% /snap/lxd/21835
  
• /dev/sda2 1.5G 210M 1.2G 16% /boot
  
• /dev/sda1 1.1G 5.3M 1.1G 1% /boot/efi
  
• /dev/sdb 2.0T 81M 1.9T 1% /mnt/ncdata
  
• tmpfs 388M 0 388M 0% /run/user/0
  

What are your assumptions about how much vhdx (dynamically expandable) should weigh with a completely empty, current-current created 2TB ext4 partition?

in my case

35Gigs for nothing

this is normal? and how to reduce if not?

did fstrim and Optimize-VHD -Mode Full did not shrink a single byte.

Answer 1

Quqas , the whole point is to have the fundamental possibility of replacing zeros with, for example, file holes (for this reason, I would not choose the vhdx format, which is not clear how to vacuumize, because these are windows specific solutions and you have an ext3 format,
consider all modern file systems are able to sparse files, this is when the file on the disk really takes up only as much space as was written to it, and there are also accompanying utilities that replace zeros with these holes
in linux, the usual cp with the --sparse=always key will copy and replace the zeros in the file with holes
look here
ps in your case, I strongly recommend a different approach (since the one described above will require you to first inflate the file to 2tb, which of course can fit on some btrfs / zfs with compression support, but it's not very efficient) it's better to backup the disk using partclone (supports huge number of file systems) this utility can copy block devices (count as dd) skipping sectors marked as free by the file system, i.e. you create a second empty disk (even if it is raw, I strongly recommend keeping the images as is ) and from a virtual machine (since vhd is difficult to mount directly, existing tools are buggy with large disks) and clone from the old to the new using clonezilla.
This approach is probably the most efficient for vacuuming disk images that rely on leaky storage.

Answer 2

as a result, after various attempts, always 35 gigs if ext4
stopped at btrfs = 200 meters (against 64raw) at the time of creation,
recognize ext4 as incompatible with Hv (it remains to be seen how it will grow when you start filling)