The SSD Revolution / An Ars Technica feature

How SSDs conquered mobile devices and modern OSes


Take a hike, conventional wisdom

In the old days before Windows, back when I was in junior high—take that, hipster digerati!—things were simple. Want to keep your computer running fast? Buy a copy of the Norton Utilities for DOS and run Speed Disk to defragment the thing. If you were one of those lunatics crazy enough to use Stacker or DoubleSpace on your drive, then you made sure you were using Norton 7 so that Speed Disk supported your insanity.

A good defrag was magic for an ailing disk, and as operating systems got smarter, disk defragmentation got more automated. For example, Windows 95 included a built-in disk defragmenter that was smart enough to detect when the contents of the disk being defragmented had been modified after the defragmenting started. It was so smart, in fact, that it would often start defragmenting the C: drive and never finish, because the operating system would blithely continue doing other I/O tasks on the C: drive while it was defragmenting. (Like all tales of comi-tragedy, this one is a lot funnier now than it was at the time.) Fortunately, future versions of Windows got a lot more intelligent about handling boot volume defragmentation, and automated defragging became a transparent feature.

"If you happen to use an SSD with Windows XP or Windows Vista, make sure that you've disabled the automatic background defragmentation."

Outside of the Windows arena, holy wars were fought on USENET and later on message boards all across the Internet about whether or not OS X's HFS+ file system truly needed defragmenting; the answer in Apple's own words seems to be not really but sometimes yes, maybe. In OS X 10.3, Apple introduced some limited automatic defragmenting with two modes of operation, with the first mode taking files smaller than 20MB and with more than eight fragments and coalescing them into a fragment-free location when they were opened for reading; the second mode (called "Hot File Adapting Clustering") moved small and frequently accessed read-only files to the fastest part of the disk.

The most common GNU/Linux file systems are ext3 and ext4, which like HFS+ can be manually defragmented, but which perform their own housekeeping and don't often need to be.

Defragmenting is a file system-level operation and is usually done because hard disk drives tend to toss files around wherever there's room to put them, and that doesn't always mean writing a file in sequence. As a disk's contents change organically over time with writes and deletions, holes open up where files used to be, and the operating system will write partial files into those holes, fragmenting the files (yes, I'm simplifying, because otherwise we'll be here for another 10,000 words, just like last time!). If the file that gets fragmented is one that needs to be read quite often, then the hard disk drive has to perform one or more extra seek operations to read the file—rather than reading the file from sequential sectors, it has to read the first part, then jump to the second part. If the file is fragmented into dozens or hundreds of pieces, which can happen, then reading that single file becomes quite a time-consuming operation. Remember the memory hierarchy—hard disk drives are the slowest part in any operation the computer performs and saddling a read with tons of extra seek operations can waste a huge amount of time.

How disk fragmentation happens

With solid state, automated defragmentation is not only unnecessary but actively bad. In the first place, SSDs are mostly immune to the effects of file system fragmentation. The majority of the latency a spinning disk experiences is because the heads have to physically swing over the right logical cylinder on the disk's surface, and then the correct track on that cylinder has to rotate underneath the heads to be read. SSDs, though, have almost no random seek penalty and no rotational latency—any given page on the entire SSD can be read just about as quickly as any other page. A truly sequential read of SSD pages will benchmark faster than a random read, because the random read involves a lot more controller overhead, but the difference is minuscule compared to the sequential vs. random read performance of even the fastest spinning hard disk. SSDs just don't care very much about fragmented files.

Of far more concern, though, is the practical effect defragmentation has on solid state disks, because defragmenting is a fast way to make a whole lot of changes to a disk. To briefly review, recall from our previous SSD feature that the NAND flash used in SSDs can only be written to one page at a time—that is, one 8,192 byte (usually) chunk, which equates to one horizontal row of NAND floating gate transistors inside of the flash chips. Further, recall that a page in an SSD cannot be overwritten. The floating gate transistors inside a NAND flash chip come from the factory containing little to no charge, and a floating gate transistor with no charge has the binary value of "1" (or "11," for a current-generation MLC floating gate holding two bits). Changing that 1 to a 0 involves pumping electrons into the floating gate and isn't too difficult, but changing a 0 back into a 1 involves convincing those electrons to leave the floating gate; much like convincing an unemployed brother-in-law to get the hell off your couch and go do something else, doing so requires quite a bit of energy.

It's very difficult to confine the erase operation to individual cells because of the amount of current involved; in fact, targeting only one cell for erasure requires even more current applied to the surrounding cells to keep them from being affected, and all this current significantly shortens the life of all of the cells. The solution is to skip on the voltage-intense process and just erase an entire flash block all at once. Since a block in a current-generation SSD contains 128 or 256 pages, SSDs try to erase them only when necessary; all modifications to SSD pages are made by writing the changes out to a whole new page and marking the old page as stale. Then, at some point when the drive's controller feels the need to do so, good pages are separated from stale pages and blocks with all stale pages are erased.

SSDs can only be erased one whole block at a time.

Fresh, blank pages are a precious commodity, and automated management of file fragmentation by the operating system eats fresh pages like a starving lion eats crippled gazelles. An SSD doesn't know anything about what files reside on its pages—files and clusters are things that the operating system knows about, but there's a line between the file side of the house and the block side of the house which is rarely crossed. A defragmentation process run on an SSD kicks off a tremendous number of new page writes; each time the OS picks up a piece of a file and relocates it, the SSD writes the changes out as new pages. Defragging a sufficiently fragmented SSD could easily blow through that SSD's entire set of free pages, with significant performance implications. When no free pages are available, every single change requires the SSD to read an entire block into cache, erase the entire block, and then re-write the entire block with the changed page. With a single block taking up as much as 2MB, this could mean 2MB worth of reading and writing just to change a single byte.

Defragging an SSD is a bad idea.

The good news is that modern operating systems understand this. Windows 7 disables its automatic defragging when it senses it's installed on an SSD, and Windows 8 does the same (Windows 8, in fact, is designed from the ground up to run on solid state storage as its preferred medium). OS X's two automated defragmenting methods appear to automatically disable themselves when used with an Apple-provided SSD—at least, the ".hotfiles.btree" file used by Hot File Adaptive Clustering is missing on the SSD-equipped Macs we had access to check. (Actual technical information from Apple on HFS+ defragmenting on SSD is annoyingly difficult to come by, and non-Apple SSD users should at least be aware of the possible issue.) File systems used by most GNU/Linux distros typically do not auto-defrag, so there's nothing to disable there.

Older operating systems are a different story. If you happen to use an SSD with Windows XP or Windows Vista, make sure that you've disabled the automatic background defragmentation (this might require some registry tweaking on Windows XP). There's more than just regular defragmentation to be turned off in XP and Vista; for example, both operating systems do their best to take files referenced during boot and move them onto the quickest part of the hard disk drive. This optimization is worse than useless on SSDs, since repeated shuffling of boot files chomps up free pages. Curbing it requires another trip into the registry.

Windows 7 contains a whole slew of performance optimizations designed to use supplementary storage—like USB thumb drives—as extra cache space in order to help overcome the problems of dealing with latency-bound hard disk drives. ReadyBoost, a technology first introduced in Windows Vista, works in concert with another technology called SuperFetch to find commonly used program and data files and cache them on a thumb drive, the theory being that accessing those files off of a thumb drive will in most cases be quicker than pulling them off of the hard disk drive, if the hard disk drive is busy servicing other I/O. SuperFetch by itself performs a more limited caching role to system RAM, but when coupled with ReadyBoost, it really comes into its own, pre-caching many gigabytes of data on a thumb drive. There's also ReadyDrive, a feature which relies on the flash buffer in hybrid hard disk drives to speed up I/O. But when it finds itself on a solid state disk, Windows 7 turns off all of these features because suddenly the bottleneck they were designed to mitigate is far smaller.

In addition to disabling old features, SSDs have required some new ones—most notably, support for a command called TRIM.

Expand full story

You must to comment.


You May Also Like