Unable to Compact 5Gb Bloat(?) - Win 10 1903 guest (clean install)

[HilltopsGM]

Upgraded from Win 10 1809 to Win 10 1903 in the Guest.
Cleaned the OS so we couldn't roll back to 1809.
Ran sysinternals sdelete command and zeroed the free space with -z -s switches selected (like I have done many times before - works great)
Ran the CloneVDI tool v3.02 (which has ALWAYS worked well) choosing the "compact drive while copying" and Keep UUID options.

The result:
The guest reports only 12.2 GB's being used.
The *.vdi file will only compact down to about 17.2 GB's

In the past I've always gotten down to about 12-13Gb's.
I'm not sure why there is 5GB's of ???? bloating the *.vdi file.

There is no page file in the guest.

I've even tried using vbox's method here: https://superuser.com/questions/529149/ ... -file-size

I've tried defraging the guest and zeroing the free space.

Does anyone have any ideas as to what is causing the bloat?
Thanks
=============
Guest is Win 10 pro 1903
Host Win 7 and Linux Mint 1803 (played with both)
VBox Version 6.0.8 r130520 (Qt5.6.2)

[mpack]

The guest reports only 12.2 GB's being used.

In one partition. I have no doubt that your drive has more than one.

[pt58]

Windows 10 V1903 introduced something called reserved storage which reserves around 7GB to ensure there's always enough free space on the drive to allow for future windows updates. Google 1903 reserved storage to read about it.

I'm a little confused though, because the thread title says (Clean Install) whereas the first line of your post says you upgraded the guest from 1809 to 1903.
Which is it?
This matters because the reserved storage only appears on a clean 1903 install, but doesn't on a 1809 to 1903 upgrade.

[HilltopsGM]

The guest reports only 12.2 GB's being used.

In one partition. I have no doubt that your drive has more than one.

Hi mpack.
I'm not sure I am following your line of thought.

The guest *.vdi file (as viewed from the host) has only 1 partition in it and is around 17Gb's.
Start that VM and it reports as just over 12 Gb's are being used.

What other partition would we be talking about?

Thanks.

[HilltopsGM]

Windows 10 V1903 introduced something called reserved storage which reserves around 7GB to ensure there's always enough free space on the drive to allow for future windows updates. Google 1903 reserved storage to read about it.

I'm a little confused though, because the thread title says (Clean Install) whereas the first line of your post says you upgraded the guest from 1809 to 1903.
Which is it?
This matters because the reserved storage only appears on a clean 1903 install, but doesn't on a 1809 to 1903 upgrade.

Thanks for the reply pt58.

I didn't know that about v1903.
Should that 'reserved space' not be reported as space being used on the drive (within the VM) . . . much like available space is less when the hybernation file (bad example in the vm) or the pagefile takes up lots of room?

(((Regarding the "Clean Install" comment)))

What I was trying to get at with that statement was there were no OTHER programs installed - just the OS.
And yes, I did upgrade it from v1809, then zeroed the free space using sysinternals sdelete, and then compressed the *.vdi file back down to as small as it would go.
That is where I noticed the difference between the compressed *.vdi file (17 Gb's) and what the Guest when running was reporting (12 Gb's).
Hopefully that makes more sense.

[mpack]

Compaction is not compression, so please don't muddy the waters. Compaction doesn't encode the drive contents, it simply deletes unwanted data irreversibly.

If your problem is that compaction in CloneVDI has limited effect, then it might be that the guest OS uses GPT partitioning (and EFI BIOS), which the current version of CloneVDI doesn't support. I'm planning a new release sometime soon to fix that.

Also, sdelete (which is not necessary if you use CloneVDI on a supported filesystem) will only zero out targetted partitions, not the entire disk. In any case if Windows hides the installer ISO contents in a hidden partition - and it will indeed be around 4GB or 5GB I think - then that data would not be regarded as unused disk space by either CloneVDI or sdelete. The data is not unused, it's just has a function that you don't consider important.

You can Google for advice on how to delete that hidden recovery partition in Windows 10, but make a backup of the VM first, and check that you know how to recover it: because the procedure involves the DiskPart command line tool and one wrong step could result in a dead VM and permanently lost data.

[HilltopsGM]

Compaction is not compression, so please don't muddy the waters. Compaction doesn't encode the drive contents, it simply deletes unwanted data irreversibly.

My apologies, I wasn't sure on the correct terminology there. Compaction is what I meant.
Also, good to know that I don't have to run sdelete too.

. . . In any case if Windows hides the installer ISO contents in a hidden partition - and it will indeed be around 4GB or 5GB I think - then that data would not be regarded as unused disk space by either CloneVDI or sdelete. The data is not unused, it's just has a function that you don't consider important.

There are the 'hidden' partitions: "System Reserved" (500MB's), and "Recovery Partition" (830MB's) on this vm's disk . . . I can live with that. But that still doesn't account for the extra (3.5 GB's). It still has me scratching my head a little.

I have learned how to disable this 'reserve partition' . . . and that it doesn't actually disappear until Windows does it's next update. Well, I've updated the vm to Windows 10 version 1909, but there still seems to be about 3-4GB's of space that is not being compacted down. (VM reporting about 12GB's [+ the 1.3 Gb's of hidden partitions] = 14.3GB's, and after VM compacted it is about 16.5Gb's).

I've cleaned the OS of it's rollback option too, so I'm still not really sure where the extra is at.

Thoughts?

[mpack]

As I said, sdelete will only target 1 selected partition. If your data is not inside that partition then it will not be zero filled and hence VBoxManage compact will do nothing.

There aren't really two options. If VBoxManage compaction doesn't reduce the disk size then there are no more zero blocks. You would have to diagnose the details yourself.

It is still the case that the current release of CloneVDI compaction doesn't currently support GPT (the partition scheme used by an EFI BIOS), meaning it can't inspect the contents of those partitions to see if they contain deleted files.