Reconditioning a solid state drive (SSD)
Frequent write activity on a solid state drive (SSD) can severely degrade its write speed, and the effect is cumulative with ongoing use. However, the degraded write speed can be fully restored. View prices on SSD
Six months of experience with the Intel X25-M solid state drive (SSD) on the Mac Pro revealed the severe degradation of write speed to roughly 1/4 of the original speed, with unpredictable pauses. This behavior was induced by intense usage of the SSD for software development, an inappropriate use for an SSD, because over time it involves the creation and deletion of untold millions of small files
Please note that the write-speed issue likely affects every brand of MLC-based solid state drive, and might be even more of a problem with some brands. It is unclear whether SLC-based drives have the same issues. (MLC and SLC are two types of chips used in solid state drives, with SLC being a server-oriented technology).
In general, most MLC-based SSD drives are not suitable for a scratch volume, or any use where file(s) are constantly written, such as software development, a scratch disk, a database, etc. Alternately, plan on reconditioning the drive every six months.However, new designs are emerging in 2010, such as those from OWC, that are enterprise-grade.
In July 2009, after using the X25-M intensely for six months, I noticed strange pauses with activities that involved writing to disk. I had been doing daily software development, in which tens of thousands (!) of files had been created and deleted dozens of times every day. In short, many millions of small files had been written and deleted over six months. This ultimately resulted in not only file system fragmentation, but internal fragmentation of the X25-M solid state drive, which can only write in 512K blocks internally.
To establish what was going on, I used DiskTester to determine the sustained write speed of the X25-M. I had previously used DiskTester to test the X25-M, and established that it could sustain speeds in the 76MB/sec range (after the May 2009 Intel firmware update, which was intended to address the write-speed degradation).
Impaired speed, odd pauses
Shown at right is actual disk throughput, marked by extended pauses between data transfers.
Apparently the X25-M had an enormous amount of internal housekeeping to do, causing it to pause between writes for long periods (“long” in a computer sense eg a good part of a second).
Highly variable write times, very slow average
Using DiskTester’s fill-volume command, I found that write speed had degraded to an average 21.5MB/sec, or about 28% of the original speed of ~76MB/sec. Read times were unaffected, and remained at about 251MB/sec. I also noted severe Mac OS X file system fragmentation.
There was huge variability in file write times, below is a small sampling (numbers at left are the file number out of 1000 files used to fill the volume). Note some files writing at 81MB/sec and some writing at 5MB/sec. Times as slow as 2MB/sec were observed.
Fixing the write performance — first attempt
As an attempt to fix the problem, I used DiskTester’s fill-volume command to write to all the free space (about 40GB out of 74GB formatted capacity). This helped, with average write speed rising to 41MB/sec, about twice the speed first observed.
More significant, it suggested that the key to restoring performance would be to erase the entire drive, so that it could be overwritten, thus allowing the internal fragmentation of the X25-M to be eliminated eg allowing the X25-M to perform housekeeping.
Doing so (again with DiskTester’s fill-volume command), raised the average write speed to 46MB/sec, but still with regular pauses between writes, as seen in the screen shot above.
Fixing the write performance — final solution PERMALINK
A second pass with fill-volume (1000 files) had little effect, and I was beginning to worry that the X25-M could not be revived to its former write speed, which led me to conclude that I would need to erase the file system on the drive, so that I could write to its entire capacity. In other words, I would need to backup the drive so that I could wipe it out and rejuvenate it.
Erasing the drive
Erasing the drive is more of a problem when it’s the boot drive.
I then booted off the spare drive, which allowed me to erase the file system on the X25-M to a fresh one, using Apple’s Disk Utility. This is trivially easy on the Mac; how to do it on Windows is left as an exercise for the reader. See my views on Windows.
The final solution
Update! A few months after this was written, a 'recondition' command was added to DiskTester, thus automating the process, whether the disk is partially full or empty (empty is better).
After erasing the drive with Disk Utility (takes a few seconds), I again used DiskTester fill-volume (1000 files) to fill the 73.46GB capacity.
But the result was still disappointing: average write speed rose, but to a still-slow 47MB/sec, way below the expected speed.
I then realized that my best chance for restoring the drive would be to write a single huge file. I did so with this DiskTester command, writing one 73GB file to the X25-M:
disktester create-files -n 1 -f 73G XBoot
After this 16-minute process, I then retested the performance using a final disktester fill-volume, and found that the entire drive now averaged write speed of 76.1MB/sec, with very little variability—problem solved. I cloned my boot volume back to the X25-M, and got on with my work.
Multiple passes needed? PERMALINK
After installing Mac OS X 10.5.8 in August, 2009, I decided to test out the process once more to determine definitively how much effort is required to recondition the X25-M.
disktester create-files --num-files 1 -test size 73G XBoot
This View the whole process as the output from DiskTester. Note: be sure to disable Spotlight for the volume during activities like this.command uses DiskTester to write a single 73GB file to the volume name (74.4GB formatted). After each “fill”, the test file was removed, and the process repeated
A total of eight (8) iterations were run with each iteration taking about 16 minutes. Here are the average write times over that 73GB file in MB/sec:
72.3, 76.8, 77.1, 77.2, 77.2, 77.2, 77.2, 77.2
Note that steady-state performance of 77.2MB/sec required four (4) iterations taking just over an hour to perform, though just two iterations yielded 99.6% of the speed. Pushing the capacity to its limits by writing a 74.4GB file on a 74.4GB volume was not explored; it seemed wise to leave slightly more than 1GB unused.
A solid state drive offers outstanding read performance, but can be subject to severe degradation of write performance when used inappropriately, or over long periods of time.
Most users should not experience the type of write-speed degradation described on this page; the amount of write activity would be highly unusual (many millions of small files created and deleted). Still, over a period of a year or longer, some users are going to run into this issue. Furthermore, it’s clear that Intel’s May 2009 firmware update does not solve the write-speed degradation issue, since the X25-M discussed here had the update.
Restoring write performance can be done in about an hour for the Intel X25-M:
- Backup the SSD onto another hard drive. A clone is your best best, and more or less mandatory if the drive is your boot drive.
- Erase the SSD with Disk Utility. You will need to boot off the clone if the SSD is your boot drive.
- Write over the entire capacity of the SSD. This can be probably be done successfully with Apple’s Disk Utility (“Erase free space”), but the fastest approach is a tool like DiskTester’s recondition command.
- Test the speed (DiskTester run-sequential), and repeat step #3 if the speed is not its best.
- Erase the SSD with Disk Utility again, then clone the backup you made in step 1 onto it. If it’s the boot drive, you can now boot off the reinvigorated drive.
This process is straightforward, and you can even use your Mac while it’s in progress. If you have a hard drive, you might want to do this every six months or so to eliminate any file system fragmentation, but you don’t need to perform step #3.