Der Sinn des "defrag" kommt aus Zeiten der mechanischen Festplatten, denn da machte es Sinn, wenn alle Daten schön hintereinander auf den Scheiben lagen, damit alles in einer Drehung ohne sehr langsames bewegen&positionieren der Lese-Köpfe gelesen werden konnte.
Bei SSDs ist es völlig wurscht, denn da verteilt der interne Controler sowie so alles wie er will und was man als Partition oder als Filesystem sieht ist stets nur eine virtuelle Ansicht.
Weil in einer Standard-OSX Installation die RecoveryPartition hinter der SystemPartition liegt, belegten die 2 Partitionen zusammen virtuell per Default immer die volle Platte... VMware ist bei dynamischem SingleFile intelligent und erkennt wieviel OSX-Systemspeicher benötigt wird, und kann so automatisch vergrößern, aber leider nicht verkleinern, weil sowas wie "sdelete -z(ero)" unter für OSX da fehlt.
Sinnvolles Verfahren:
- man vergrößere per VMware das VMDK um etwas mehr als die Größe der RecoveryPartition
- man verschiebe mit "gparted" die RecoveryPartition ans Ende
- man verschiebe mit "gparted" die SystemPartition nach hinten wieder direkt vor die RecoveryPartition
- man verschiebe mit "gparted" die RecoveryPartition nach vorne an den Anfang des nun dort ja freien Platzes
- man verschiebe mit "gparted" die SystemPartition wieder etwas nach vorn, also nun direkt hinter die RecoveryPartition
- man vergrößere mit "gparted" die SystemPartition nach hinten bis ans Ende zur sinnvollen Nutzung des ganz am Anfang zugefügten Speichers
- man kontrolliere im OSX "Festplattendienstprogramm" ob alles passt
=> ab nun kann man unter OSX je nach Füllstand der SystemPartition diese auch direkt unter OSX verkleinern und dann wird unter VMware bei "VMDK-Compact" das VMDK auch wirklich kleiner
-> man sollte sowas nur mit 100% Vollbackup der VMs bzw. eines RealMAC machen, denn Stromausfall bei einem der Punkte wäre keine gute Idee
