With smarter file systems and faster disks and PCs, file fragmentation isn’t the performance suck it once was. Older computers had a habit of splitting files and spreading the parts all over your hard drives, but modern ones don’t do this as much. Not even close. That said, a bimonthly pass with a capable defragger can help you maintain peak performance on a heavily used hard drive.
However, solid-state drives, which use flash memory instead of a hard-drive platter to store data, are another story: My tests showed little or no benefit from running a number of disk defragmenters on a heavily used SSD.
"I found no hard evidence about SSD defragging anywhere I looked, so I decided to gather my own." Conventional logic dictates that you should never defrag an SSD, because the SSD controller writes data in a scattershot-fashion to multiple NAND chips and locations, using algorithms that only the controller understands. The operating system sees it as a hard drive with sectors, but the data is spread all over the drive by the controller. Defragging these “sectors” is like trying to assemble a jigsaw puzzle blindfolded: You can feel parts of the pattern, but you can’t see the whole picture. In addition, NAND is good for only a few thousand write cycles, so defragging can reduce the SSD’s lifespan by unnecessarily writing data to it.
Despite those arguments, at least four defragging utilities purport to increase SSD performance through optimization: Auslogic’s Disk Defrag Pro, Condusiv’s Diskeeper, Raxco’s PerfectDisk, and SlimCleaner Intelligent Defrag. To understand how these might be of benefit, let’s review a few facts.
Used NAND cells (the parts of flash memory that holds the data) must be erased before they can be written to.
Early SSDs put off erasures, simply marking cells as no longer used when you deleted a file. When fresh cells ran out, having to erase the marked/used cells before rewriting to them slowed performance.
The advent of the TRIM command, which invokes a drive’s built-in garbage collection routines (including erasing unused, previously written cells), solved the problem.
Windows 7 and Windows 8 support the TRIM command.
If you read the documentation used to support most SSD optimization claims, you’ll notice that much of it predates Windows 7 and the TRIM command. Before that, free-space optimization could force an SSD into garbage collection and thereby regain lost performance. But on a modern SSD running with a modern operating system, many of these optimizations are no longer needed.
The issue: When I investigated, no SSD vendor would state unequivocally that the defragging programs would or wouldn’t benefit a modern SSD running on a modern TRIM-supporting operating system. I could find no hard evidence anywhere I looked, so I decided to gather my own.
To that end, I grabbed a fast 128GB, SATA 6-gigabits-per-second OCZ Vertex 4 SSD, ran CrystalDiskMark on it in its virgin state, and then used PassMark’s Fragger and Joseph Cox’s program (also called Fragger) to seriously fragment the drive. I again ran CrystalDiskMark, and saw a 10 percent drop in sequential read speed. That’s a significant performance hit (although in real life you’re not likely to notice the difference).
I then gave each program its chance to optimize the drive, using its own default settings. Between each test, I performed a secure erase on the SSD (which should erase all used cells) and then restored an image of the fragmentation.
The problem here is that there’s no way to say whether the data in the image was actually distributed to the same cells. However, the level of reduced performance remained the same and, after a secure erase, increased back to nearly mint-condition level. I also tested the programs with the hardware they were meant to be used on: a standard hard drive.
To find out how the defraggers performed, see the results on the next page.
Jon L. Jacobi has worked with computers since you flipped switches and punched cards to program them. He studied music at Juilliard, and now he power-mods his car for kicks.More by Jon L. Jacobi
View the original article here
No comments:
Post a Comment