"we have noticed over time is that the provisioned size on the VM is different from the object size"
If you provision a 100GB vmdk (FTT=1,RAID1) and put 10GB of data on it, it will take up 20GB on disk not 200GB as vmdk are thin (Object Space Reservation=0) unless specified otherwise. Thus over time the capacity usage of vmdk data will grow as data is added at the Guest-OS level.
"We also realize that file deletions inside the VM do not reduce the object size and metadata overhead for vsan objects can increase the size."
Space reclaimation (TRIM/UNMAP) from deletions from Guest-OS level was only introduced in vSAN 6.7 U1 and also is not enabled by default - any version before this or on 6.7 U1 but not configured won't reclaim space. However it will use space freed up as opposed to growing the Object, e.g. if I create a 100GB vmdk, put 10GB of data on it, delete the 10GB of data and then add another 10GB it will re-use the space from the deleted 10GB of data.
That is what we seen but we have done some extensive tests on Ext4 and it does not seem to be very good at using blocks reclaimed from deletions it seems to prefer blocks that have not been used
Windows (later versions) does seem to better at doing this
Good point, I should have said *may* reuse the space as it depends on the Guest-OS/filesystem which can of course vary widely.
Documented examples indeed imply NTFS (Windows2012R2) and that is also what I would have generally been using in homelabs, also Cormac points out the caveat with EXT4:
I had a quick research into it and there are perhaps methods of zeroing only unallocated blocks but I haven't tested it so can't say whether it will apply in your case:
Thus I would advise trying the above and/or having a deeper luck and/or asking a Linux-admin (if you are not one yourself).