I know that there is no point (in fact it is a bad idea) to run Defrag on an SSD. What about a virtual machine running on an SSD, should I defrag it's hard drive since it is basically accessing the Hard Drive the same way?
-
No idea why this is on SO, but might be relevant: stackoverflow.com/questions/281527/…– Oliver SalzburgFeb 9, 2012 at 17:58
-
VSS can cause storage to grow if you don't use a VSS aware defragmenter.– user511463Oct 19, 2015 at 18:51
-
Only if the defrag option is part of your virtualisation software.– qasdfdsaqOct 19, 2015 at 20:03
9 Answers
I do defrag my VHDs but for reasons of space, not time:
I use the dynamically-allocated option for VHDs, so they start small and expand as needed. But as the VHD (not necessarily the files) becomes fragmented, it expands to include all of the allocated blocks. Defragging the VHD is the first step to compacting it again.
-
The space factor might be relevant because the VM is on an SSD, though in general, defragging anything on an SSD isn't needed for performance reasons and is discouraged. Feb 13, 2012 at 22:15
There is no need to defrag an SSD. A regular hard drive has to spin in order to find (the parts of) files. An SSD is comparable to RAM, all files can be reached with the same delay.
Wikipedia states that "Read performance does not change based on where data is stored on an SSD"
-
-
1
This is my opinion only, I don't have test results to back it up. Here's a rough approximation of how things probably happen:
Real OS:
- Application asks for data X (fast)
- OS asks disk driver for data X (fast)
- Physical disk fetches data X and returns it to OS (slow if fragmented)
Here would be the equivalent chain of command in a VM:
- VM application asks for data X (fast)
- VM OS asks data X (fast)
- VM host asks real OS to get data X stored in virtual disk file (fast)
- Real OS asks disk driver to get data X (fast)
- Physical disk fetch data X and returns it to OS (slow if fragmented).
As you can see, in both cases fragmentation only really becomes an issue at stage of the operation where the physical hard drive tries to read the data, and that happens in the real OS, outside the VM context. Prior to that, everything likely happens in memory.
In conclusion, since we know that SSDs do not suffer from fragmentation in the real OS, and that the issue of fragmentation in a VM probably only occur at the last physical step of the operation, I would guess that defragmenting either your virtual OS or the virtual disk file in your main OS would not improve performance on a SSD, while being as detrimental/useless as defragging your real OS is.
Edit: And if that's correct, it's a damn good reason to put a VM on a SSD! On a HDD, fragmentation at any stage (guest OS, virtual disk file, real OS) will break linearity and cause fragmentation at the physical disk step.
Whether your Virtual Machine is accessing data that is stored on traditional magnetic HDD or electronic SSD, Windows NTFS file & free space fragmentation slows down the access speed of applications requesting data. NTFS file and free space fragmentation happens far more frequently than you might guess. It has the potential to happen as soon as you install the operating system. It can happen when you install applications or system updates, access the internet, download and save photos, create e-mail, office documents, etc… It is a normal occurrence and behavior of the computer system, but does have a negative effect on over all application and system performance. As fragmentation happens the computer system and underlying storage is performing more work than necessary. Each I/O request takes a measurable amount of time. Even in SSD environments there is no such thing as an “instant” I/O request. Any time an application requests to read or write data and that request is split into additional I/O requests it causes more work to be done. This extra work causes a delay right at that very moment in time.
Disk drives have gotten faster over the years, but so have CPUs. In fact, the gap between the difference in speed between hard disks and CPU has actually widened. This means that applications can get plenty of CPU cycles, but they are still starving to get the data from the storage. What’s more, the amount of data that is being stored has increased dramatically. Just think of all those digital photos taken and shared over the holidays. Each photo use to be approximately 1MB in size, now they are exceeding 15MB per photo and some go way beyond that. Video editing and rendering and storage of digital movies have also become quite popular and as a result applications are manipulating hundreds of Gigabytes of data. With typical disk cluster sizes of 4k, a 15MB size file could potentially be fragmented into nearly 4,000 extents. This means an extra 4,000 disk I/O requests are required to read or write the file. No matter what type of storage, it will simply take longer to complete the operation.
The physical placement of data on an SSD doesn’t really matter like it does on regular magnetic HDDs. With an SSD there is no rotational latency or seek time to contend with. Many experts assume that fragmentation is no longer a problem, but the application data access speed isn’t just defined in those terms. Each and every I/O request performed takes a measurable amount of time. SSD’s are fast, but they are not instantaneous. Windows NTFS file system does not behave any differently because the underlying storage is an SSD vs. HDD and therefore fragmentation still occurs. Reducing the unnecessary I/O’s by preventing and eradicating the fragmentation reduces the number of I/O requests and as a result speeds up application data response time and improve the overall lifespan of the SSD. In essence, this makes for more sequential I/O operations which is generally faster and outperforms random writes.
In addition, SSD’s require that old data be erased before new data is written over it, rather than just writing over the old information as with HDDs. This doubles the wear and tear and can cause major issues with the speed performance and lifespan of the SSD. Most SSD manufactures have very sophisticated wear-leveling technologies to help with this. The principle issue is write speed degradation due to free space fragmentation. Small free spaces scattered across the SSD causes the NTFS file system to write a file in fragmented pieces to those small available free spaces. This has the effect of causing more random I/O traffic that is slower than sequential operations.
I have benchmark results to back this up. If you want, post a comment, requesting these results, and I'd be happy to share them with you.
-
Howard Butler, you are new to this site, welcome. In general, it is really ill advised to publish personal information on the internet.– wizlogFeb 13, 2012 at 20:24
-
@wizlog There is nothing wrong with posting personal information on the Internet if the information is your own. However, for purposes on StackExchange, posting your contact information or 'signature' in an answer is redundant. Users can click through to your profile for more information if they wish.– iglvzxFeb 13, 2012 at 20:37
-
With regards to the original question of a traditional defrag of an SSD, I do agree it is a bad idea, but there are specific solutions available that address the concerns of file movement and SSD lifespan.
A virtual machine that is running Windows as its operating system, fragmentation will still occur and the combined effect of the extra I/O traffic will reduce the speed and efficiency of not only the guest systems, but that of the host as well. Both Microsoft and VMware recommend the need to address fragmentation at the guest level.
Here’s why…
Application asks for data X
Request is processed by NTFS.sys
The file attributes are examined ($MFT) and if the data is not contained in a single extent (fragment) then additional I/O requests are created for each extent/fragment to satisfy the original data request.
Each of these requests are then sent to the disk storage driver.
Once the data is retrieved it is passed back up the stack to the user/application.
Each Windows virtual machine is sending this type of I/O traffic to the Host system. If the file system structure is fragmented at the Guest/Virtual machine level then this translates into additional and unnecessary I/O traffic having to be handled by the Host and farmed out the backend storage. This gets further compounded as you add more and more virtual machines. In fact, you can have fragmentation within fragmentation at the host file system level.
Whether the data is stored on an SSD or a traditional HDD, if you are running Windows the NTFS file system will become fragmented and as a result you will never achieve the manufactures rated speed and throughput due to NTFS file and free space fragmentation. The effects can be measured via PerfMon by looking at Average Disk Read Queue Length, Average Write Queue Length, and most importantly Split IO/Sec.
Starting with Windows Server 2008 and Windows Vista, be careful with Windows default scheduled defrag task.
It can be disabled with : schtasks /change / tn “microsoft\windows\defrag\ScheduledDefrag” /disable
or using PowerShell:
Get-ScheduledTask ScheduledDefrag | Disable-ScheduledTask
Extracted from: http://www.sysadmit.com/2015/10/vmware-y-gpo-defrag-windows.html
-
Can you define "be careful"? Why are you suggesting to disable the schedule? Feb 7 at 19:51
-
I've just defragmented a VMLite XPMode VM using windows defrag hosted on 240Gb INTEL SSDSC2CW240A3.
Pre Defrag VM size on host - 7.83Gb (Used space on C: on VM, 5.81Gb of 121Gb)
Post defrag - 9.86Gb (Used space on C: on VM, 5.80Gb of 121Gb)
Not the result I expected and I have restored the pre defrag version.
First of all, backup your virtual machines, as they are, before trying this stuff.
For windows virtual machines, I will sometime de-fragment the virtual drives prior to zero-ing out free space using sdelete:
sdelete64.exe -z c:
This is a prerequisite if you intend to shrink a dynamically-allocated virtual disk. Yet, even if you don't shrink them, de-fragmented virtual machines with zeroed-out free space often produce compressed backups that are smaller.
I recently reduced a virtual machine's compressed backup size from 198.99 GB to 172.96 GB (a 26 Gigabyte reduction in size), using these very techniques and the exact same compression algorithm was used before and after implementing them.
However, be warned: While the compressed backup may get smaller, zeroing out will make the running virtual machine use maximum disk space on the host. It will enlarge dynamically-allocated virtual disk to their max size! Make sure you have enough real physical space on the host before trying it.
I mainly only do this stuff when I want to shrink a dynamically-allocated virtual disk; they'll shrink smaller if everything is de-fragmented and free space is zeroed out.
The only other time I do this, is when I'm trying to shrink a windows disk partition using Windows Disk Management. This too shrinks better with de-fragmentation, but doesn't require zeroing out.
I would never de-fragment as a means to increase performance on an SSD, and the things I mention above are not for that purpose.
No, not really. There are stuff like "Hyperfast" by Diskeeper, but I have no idea how efficient these technologies are. (It's maybe just a ripoff so they won't fall off the market after SSD will become mainstream.)