The Network: U.S. East Coast data center of a nationwide retailer. Its up-to-date equipment includes a significant investment in Solid State Disk (SSD) technology deployed in SAN arrays. This is quite different than individual SSDs that are now common in tablets or high end laptops.
The Expectation: SSDs aren’t cheap but their performance is orders of magnitude better than even 15K RPM drives. Conventional wisdom says SSDs don’t last forever, and when they die, they just poof and die. SSDs can only handle a finite number of writes before things start going bad, so avoid writes that are perceived as unnecessary.
The Catch: The EventTracker Windows sensor observed defrag.exe, a Microsoft executable, was launched on a 2012 R2 server by the Windows Scheduler with the command line DEFRAG.EXE -C -H -K -G -$. Conventional wisdom says this is a bad thing, right? Moreover, is a single SSD, the same as an array in a SAN? Where is defrag handled?
The Find: Upon closer examination, it seems that conventional wisdom is out of date and inaccurate for even consumer machines running Windows 8 or servers running local SSDs under Server 2008 R2 or higher. As noted here, “Windows does sometimes defragment SSDs, yes, it’s important to intelligently and appropriately defrag SSDs, and yes, Windows is smart about how it treats your SSD.” Thus it’s ok for the defrag command to be scheduled for local disks including SSDs. However, in a SAN array, the defrag function is typically handled at the array level and not by the individual machines connecting to SAN. In this case, this auto scheduled defrag on each server going against SAN array mounted disks in unnecessary, and harmful for SSDs.
The Fix: Change the default settings in 2008 R2 or 2012 R2 to avoid scheduled defrag of SAN arrays. It’s fine to defrag local SSDs, as Windows is smart about it.
The Lesson: Defaults are carefully chosen to be suitable for the most common configurations. SAN arrays and data center configurations are special and much less common. Care is needed.