You already said that, and I already answered: no, there is nothing like "MUST". And in fact if you don´t know exactly what you are doing and why, you WILL end in a worse state, possibly much worse.
AidenShaw just explained it allright.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Intel's Z68 Chipset and SSD Caching Reviewed
- Thread starter MacRumors
- Start date
- Sort by reaction score
You already said that, and I already answered: no, there is nothing like "MUST". And in fact if you don´t know exactly what you are doing and why, you WILL end in a worse state, possibly much worse.
AidenShaw just explained it allright.
How would I end in a much worse state if I already had to do that to go from absolute thrashing to normal performance again?
Have you already tried reading AidenShaw's post?
Simple example 1: if you do a defrag of the virtual disk and nothing more, the performance will either stay the same or go worse, because the disk image is still as fragmented as in the beginning. And if the disk image was a sparse one, surely it will have grown a lot at the end, surely becoming even more fragmented.
Simple example 2: if you do a defrag of the host disk and nothing more, the performance will either stay the same or go worse, because the virtual disk is still as fragmented as in the beginning.
Summary: you need to defrag both disks (virtual and host), and in the correct order, for it to make sense. If you don't, the effect could be all the way from small to much worse. And then you probably will want to zero the extra space in the virtual disk, and maybe even use any internal defrag routine specific for the format of the disk image (VMware had one if I remember correctly, VirtualBox maybe too). And of course, if you use any minimally advanced feature (like snapshots), defragmenting the virtual disk will be terrible: horrible performance, lots of space wasted.
Again, I recommend you to read AidenShaw's post.
It's not a matter of raw space, but percentage.
You shouldn't let a drive fill up much past 80%, or it starts to impact the ability of the filesystem agorithms to efficiently place files. This is particularly true if you have a lot of write activity, even more so when dealing with large files.
If your drive is so full that only a few gigs are left, it is probably the cause of your thrashing (outside of doing something silly like running half a dozen VMs from a single spindle). Defragmenting - outside of corner cases - rarely makes any meaningful performance difference.
Last edited:
Then the iMac isn't that good after all. I wanted to buy the iMac but I changed my mind after reading this. I thought that there was SSD caching, but *sigh*. Maybe the next Macbook Air.
I defragged both virtual and real disks. It was obvious that that's what needed to be done.
I don't use complicated virtualization stuff, just 1 vdi per VM.
Hmm. I just don't ever remember being told that we should do that when using ESXi with SAN storage. I mean yeah you can defrag the guest, but the host doesn't (typically) provide a way of doing that.
Good info nonetheless. Thanks Aiden!
never mind....
Note that the comments that I made are in reference to expandable and snapshotable virtual disks.
Often with VMware ESX-based hosts one uses statically-allocated disks (when you create a 40 GB virtual disk, it creates a 40 GiB file to hold the data). You are guaranteed the LBA X is immediately after LBA X-1, and that the VBA for X is immediately after the VBA for VBA x-1 in the .VMDK file. (This also applies to "persistent" VMDKs on VMware hosted systems - when you create a 40 GB disk, it creates a 40 GiB .VMDK file. (VMware hasn't adopted the correct interpretation of "GB", unfortunately.))
For these "pre-allocated" virtual disks, you only need to defragment the VMDK file once, if at all. Since it's preallocated, there is no expansion, and there are no snapshots.
During use, you may want to defragment the disk from the guest - since sh#t happens. You never need to defragment the VMDK file again though - it doesn't expand, so once it's contiguous it stays that way.
Note also that if a multi-gigabyte VMDK file is in a handfull of fragments, there's no point in defragmenting. You might save an occasional I/O if it's perfectly contiguous - but you won't notice any difference.
Note that the comments that I made are in reference to expandable and snapshotable virtual disks.
Often with VMware ESX-based hosts one uses statically-allocated disks (when you create a 40 GB virtual disk, it creates a 40 GiB file to hold the data). You are guaranteed the LBA X is immediately after LBA X-1, and that the VBA for X is immediately after the VBA for VBA x-1 in the .VMDK file. (This also applies to "persistent" VMDKs on VMware hosted systems - when you create a 40 GB disk, it creates a 40 GiB .VMDK file. (VMware hasn't adopted the correct interpretation of "GB", unfortunately.))
For these "pre-allocated" virtual disks, you only need to defragment the VMDK file once, if at all. Since it's preallocated, there is no expansion, and there are no snapshots.
During use, you may want to defragment the disk from the guest - since sh#t happens. You never need to defragment the VMDK file again though - it doesn't expand, so once it's contiguous it stays that way.
Note also that if a multi-gigabyte VMDK file is in a handfull of fragments, there's no point in defragmenting. You might save an occasional I/O if it's perfectly contiguous - but you won't notice any difference.
We don't know yet that the new iMac won't have SSD caching.
And it seems unlikely that Apple would reintroduce an HDD into the MacBook Air, unless I'm missing something.
Obvious? Well, I hope that you did the virtual first and the host last. If not, you did nothing - or maybe worse than nothing.
I also hope that you did check if the disk image needs any specific defragmentation. Like step 2 in these VMware instructions, for example. If not, you still have possibly lots of fragmentation to fight. (Also, note that it has to happen between virtual and host defragmentation to be effective!)
And I also hope that your VM is not doing automatic snapshots, like VMware Fusion does ("AutoProtect"). If it does, you got definitely worse by doing the defrag. Although surely it will "heal" itself, ... eventually.
No clones? No snapshots, even automatic? No growing disks?
Oh, then you´re good.