VMware Communities
gringley
Hot Shot
Hot Shot

Revisiting Disk Shrinks

I was revisiting disk shrinking today as a number of my newer macOS guests were over 100GB.  In macOS 11.0 and 12.0 I have one guest that shrunk back to its "normal" size, but the rest are bigger.  Like the 11.0 guests are 20GB used in macOS, but 65GB used on disk by the vmdk?  I use the method of creating the wipefile then shutting down and running -d then -k from the host terminal.  I cannot identify a reason why this is happening?  Anybody have some insight on this?

P.S: For those of you that are curious about these things, when I logged in my MPSA to get Windows 10 22H2 ISOs, I found I could download Windows 10 ARM ISOs going back to 20H2 (Nov 2020).  No idea why Microsoft has suddenly become so helpful in this regard?

Reply
0 Kudos
12 Replies
Technogeezer
Immortal
Immortal

I'm wondering if you are seeing APFS in action.

If you rewrite a block on an APFS file system, that block is going to be newly allocated somewhere else in the file system. It's not written back to the original block.

The old block will have its reference count decremented and if it goes to zero will be put back as a free block.  The reference count is important because if you have a snapshot active that needs that block, it means that the reference count hasn't dropped back to zero and the block still remains.

APFS eventually fragments the disk because of this method of managing file system block allocation. It's also made worse if you have multiple APFS volumes sharing the space in the same container (which happens on a APFS boot disk because it not only contains the read only Macintosh HD file system, but the read-write Data volume and the virtual memory swapfile volume), and the Preboot volume)..

Fragmentation is not a problem for SSD devices. It is a big problem for HDDs

There's no way to defragment that APFS file system, so there's no way to get the "holes" out of the disk and get a big unallocated chunk of disk space at the end of the disk. Writing zeros to the wipe file therefore does not write zeros to a "big contiguous unallocated area at the end of the disk" which the VMware command line utilities recognize as "deleted space that I can use to shrink the VM". 

Fragmentation due to APFS behavior is a major reason why APFS is not a good choice for an actively randomly read and written HDD (or why APFS makes a poor choice for a HDD equipped Macs or bootable cloned system disks). 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
ColoradoMarmot
Champion
Champion

The only way around the guest issue I know of is to make a new VM, mount that boot drive in the guest, then use something like carbon copy cloner to clone the old disk to the new one, then switch to the new VM.  I haven't validated that'll work on guests newer than Catalina though, but it might be worth a try.

I've also noticed that mounting an encrypted APFS spinning disk takes a VERY long time (2-3x longer than an encrypted HPFS disk).  I really need to bite the bullet and reformat my external drives back to HPFS+.  Unfortunately, I'm not sure you can format a RAID array without using HPFS these days.

Reply
0 Kudos
ColoradoMarmot
Champion
Champion

Argh, the forum bug bites again - can't edit my post (edit reply doesn't do anything).  I meant RAID without APFS.

Reply
0 Kudos
gringley
Hot Shot
Hot Shot

The guests are all APFS so this is making some sense.  I am thinking revisit this with Fusion.next or whatever is coming soon and see if it changes before putting any more effort into it.

I do use Apple RAID with a pair of external SSDs and a pair of External HDDs, and I recall that OWC's RAID required HPFS but Apple RAID could do APFS so I decided to do Apple to have one less third party dependency.  The Blackmagic(?) benchmarks on the SSD RAID tended to vary quite a bit so maybe the encryption thing is a performance problem? 

Reply
0 Kudos
Technogeezer
Immortal
Immortal


@gringley wrote:

The guests are all APFS so this is making some sense.  I am thinking revisit this with Fusion.next or whatever is coming soon and see if it changes before putting any more effort into it.

I wouldn’t expect this to change, as I think it would take some major changes to how VMware implements split virtual disks. I also don’t see Apple building a defragmenter for APFS given they built it primarily for SSDs that don’t have issues with seek time and rotational latency. 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
gringley
Hot Shot
Hot Shot

I am seeing the shrinking is still worth doing at least once in a while.  My Ventura beta had grown to 109 GB.  In regards to the filesystem issues I saw that the wipe file which should have grown it to 200GB - didn't.  After -k the vmdk shrunk to 35GB which matched what the OS said was in use.  For 13.1 it worked!  So my 11.0 guests are 65GB after shrinking but only 25GB or so in use.  The 12.0 guests that had Xcode on them have the same general issue but the vmdks are in the 40-50GB range.  The 12.0 that was a "straight desktop" shrunk as desired and so did the now 13.1 beta that has Xcode on it.  So it does seem to be getting better over time but I have no idea why at this point?

Reply
0 Kudos
Technogeezer
Immortal
Immortal

Have you taken a look at the sizes of the "sliced" files that make up the VM;s virtual disk? I wonder if the APFS write behavior opened up some significant sized "holes' in the "middle" of the disk - which would mean that some of the sliced files in the "middle" part of the virtual disk that aren't at their full 4GB max size. 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
gringley
Hot Shot
Hot Shot

I went back and rechecked my work with Daisy Disk, and found that by and large the shrinks worked on all of the guests except the 11.0 "Desktop."  My 11.0 guest with Xcode had 15GB in "Sandbox" in the System folder and 17GB in the Xcode application so that where its space went.  The 11.0 with the missing space I enabled APFS Defragmentation on, and we'll see what it looks like after the next macOS 11 update as I am guessing I need the OS update to toss the files around enough to make a difference.

Reply
0 Kudos
Technogeezer
Immortal
Immortal

Let us know how the APFS defragmenter works. I'm curious as to how deep they've gone with it. It's one thing to collapse file block allocations so that files are more contiguous, it's another to "slide the files toward the start of the disk" to consolidate free space.

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
Reply
0 Kudos
gringley
Hot Shot
Hot Shot

I checked things today with the latest round of updates applied, and all my "modern era" macOS disks shrunk as expected this time.  This includes the 11.0 disks.  

Reply
0 Kudos
ColoradoMarmot
Champion
Champion

Interesting - my linux guests under 13 (M1) don't even have a shrink option anymore.

Reply
0 Kudos
gringley
Hot Shot
Hot Shot

I usually do not bother with Linux guests as they do not get "out of control" disk spacewise like the Mac ones do.  The automatic shrinks for Windows works on M1 so that is a good thing.  The shrink process I am using is a manual one that is documented across a number of old posts here, but I will recap it.  In the guest I first run a script to zero the disk space:

#!/bin/sh
cat /dev/zero > wipefile; rm wipefile
sudo halt

Then in macOS Terminal I run these commands on the VMDK file:

/Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -d Virtual\ Disk.vmdk

/Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -k Virtual\ Disk.vmdk

I think on my older Mac guests the VMtool shrinks were done from inside the guest but that no longer works in the "modern era."

 

Reply
0 Kudos