Atomic I/O letters column #123Originally published 2011, in Atomic: Maximum Power Computing
Reprinted here November 24, 2011 Last modified 16-Jan-2015.
String, piece, length of, further enquiries
In your last column, you explained why there was no way to tell what brand of hard drive was best. So I'm not optimistic about getting a positive answer to this question, but here goes anyway: Are SSDs more reliable than hard drives?
There are plenty of SSD horror stories on the web, but I suppose part of the problem is that SSDs are developing fast, so how long last year's model of SSD lived means even less than what the last generation of hard drives did.
Still, if it's possible to know how reliable SSDs are for 30 times the price per GB of a HDD, I'd like to know!
Short answer: Nobody knows.
Long answer: Uh, how long have you got?
Drive durability depends on a large number of variables. You can rule out only some of them by restricting your survey to "normal" usage profiles, for home PCs that do Web browsing, boring office apps, and games.
Many of the people most in love with SSDs are not these "normal" users. Instead, they need to work intensively on datasets much larger than even a serious PC's RAM. The main SSD performance advantage, near-zero latency, is a huge plus for this. Compiling large programs, scientific computing, serving databases to lots of users, that sort of thing.
In these cases, the user may not even much care if their SSDs only live an average of 12 months. Sure, it's annoying to lose a day's work and then maybe a whole extra day restoring backups and patching holes, but in those 12 months SSDs can get as much disk-intensive work done as 18, or more, months with mechanical hard drives.
Us regular schmoes with "normal" PCs may not be so entranced by a lightning-fast disk subsystem, if the downside is truly much lower drive lifespan.
The only SSD-life risk factor I'd be willing to bet a modest amount of money on being real, though, is excessive writes, usually caused by putting your swap file on your SSD.
SSDs are, performance-wise, an excellent place to put your swap file, and even low-end SSDs now have enough capacity that their wear-leveling firmware should be able to spread constant swap-file writes over the physical memory cells and, according to specification-sheet write-tolerance numbers, give several years of service.
But SSDs that cark it in the first year are, as you've noticed, not unknown.
I think, again without a very large amount of confidence, that one reason for the surprising number of failure reports may be that the vast majority of current consumer SSDs, and all of the cheaper-per-gig models, use multi-level cell (MLC) flash RAM, instead of single-level cell (SLC). SLC stores one bit per memory cell; MLC stores more than one (typically two), and is slower and less reliable.
It's impossible to tell how representative the complaints are, though. If you spend $500 on an SSD with much less capacity than a $200 hard drive, and your expensive SSD drops dead young, you are probably more likely to complain online than someone who has a similar experience with a cheap hard drive. Dissatisfied users in general are more likely to speak up than satisfied ones, though, so a product with a 0.01% failure rate and ten million units in the field can easily seem less reliable, per user reports, than one with a 3% failure rate and only 25,000 units sold. So the problem could actually be much worse than the prevalence of dead-SSD complaints suggests.
For what it's worth, most of the drive companies have officially stated that SSDs are, if anything, more reliable than spinning disks, and they've backed up these statements with similar warranties to the ones you get on hard drives. Some of the Mean Time Between Failure figures for SSDs are even more ridiculous than those for spinning disks.
Some people reckon SSD failure rates may be rather alarming, but the extra performance makes the death rate acceptable. Others say that at least as far as retailers' return-rate statistics go, SSDs seem quite reliable.
Tom's Hardware had a stab at the problem earlier this year; they concluded that both consumer and "enterprise" SSDs do seem to be significantly less reliable than spinning disks, and that the drive manufacturers seem to be understating failure rates.
I've always said that you should expect your hard drives to die at the age of two. They'll probably live longer than that, but given the endless plummet of storage prices and how easy, relatively speaking, it is to clone a working boot drive onto a new device, bi-yearly drive replacement is not a bad idea.
And you can extend this to SSDs, too. All you have to do is have enough hard-drive space to hold an image of your boot SSD, and then image the SSD to the spinning disk regularly. It's easy to do this with something like DriveImage XML, the basic version of which is free, and which can image a boot drive while Windows is still running.
(Actually, I tell a lie. It used to be easy to clone a Windows boot drive, but as of Windows Vista Microsoft decided to bake a unique identifier, which is hard to clone, into the Boot Configuration Data of every drive. Cloning data drives on a Vista or Windows 7 computer remains easy; cloning the boot drive can now be an exercise in frustration. I've repressed my memories of the last time I tried to do this, but I think the best way I found, after cursing over various Shadow-Copy-based cloners and Linux Live CDs, was with the free version of EaseUS Todo Backup. If any of you readers know of a truly sure-fire Vista/Win7 boot-drive cloner, tell me and I'll mention it here.)
UPDATE: After this page went up, numerous readers recommended that I should just use Windows Backup, which can make a disk image on another drive and then create a boot DVD that'll write the image back onto a new drive. And yes, this works!
In Windows 7, you open Backup and Restore in Control Panel, and then "Create a system image" of your boot drive, on another drive. (This does of course mean that you need another hard drive in your computer, or an external drive, with enough space on it for all of the data on your boot drive.)
Next, "Create a system repair disc", if you don't have one already; this step is not essential, if you've got a Windows 7 install disc you can boot from instead. (You'll need a blank CD and a CD writer to do this, of course; you can make a System Repair Disc on a writable DVD too, but there's less than 200Mb of data on one, so a CD is fine.)
Now, shut down the computer, remove your old boot drive, install the new drive, and boot from your System Repair Disc (or Windows install disc). Select "Restore your computer using a system image that you created earlier" (if you've booted from an install disc you'll need to pick a "repair" option to get to this menu), select the image you want and the drive to write it to.
(It's impossible to write an image to the drive the image is on, but you can accidentally write the image onto the wrong drive, if there are more than two drives connected. If this makes you nervous, just temporarily unplug any extra drives before you boot from the Recovery Disc.)
When the image is written, boot from the CD again and select "Startup Repair", and point it at your new boot drive; when you restart after doing that, your new boot drive should be working.
I can't figure out what the hosts file is for. Apparently you can use it to block ads and viruses, and apparently you can also use it to completely break your ability to use unimportant things like, say, Google.
What's it do?
I'm pretty sure you can do without most of these domain names.
The hosts file is a piece of low-level network configuration that's actually quite safe to play with.
In Windows, it's just called "hosts" with no suffix, and located by default in C:\Windows\System32\drivers\etc (presuming your boot drive is C). It's a way of circumventing DNS.
DNS, the Domain Name System, is what your computer uses to turn www.example.com into the IP address for the example.com server, 188.8.131.52. Your computer sends the example.com request to the DNS server at your ISP, which can in turn ask more and more important DNS servers all the way to the Internet's "root nameservers", if it doesn't have an answer already. One or another DNS nameserver finds the IP address for the domain name (if the domain actually exists), and hands it back to your browser or online game client or whatever. If you already know the IP address for some reason, you could use it directly - just type it into the address box in your browser - and not bother with the domain name at all.
There's more complexity here - like, for instance, DNS returns the IP address 184.108.40.206 if you ask it for www.atomicmpc.com.au, but typing that IP address into your browser will give you a Haymarket Media error page, because the server can't tell what domain, of the several run by Atomic's publishing company and hosted by the same server, you were looking for. Usually it's simpler than this; the current IP address of the dansdata.com server, for instance, is 220.127.116.11; click that link and you'll get my home page, without any help from DNS at all.
So the basic function of DNS is resolving host names into IP addresses. This is exactly what a hosts file does, too - except it resolves host names into whatever IP addresses you put in the file, not the addresses DNS would give you.
The operating system always looks at the hosts file before it talks to any real DNS server, so any host you block in the hosts file will never be resolvable.
The hosts file is plain text, and the lines in it that do something are the ones that start with an IP address and end with a domain name. (Lines that start with a # are comments, human-readable but ignored by the operating system.)
To use a hosts file to block a domain, you just assign some harmless IP address, traditionally the "localhost" address 127.0.0.1, to every domain from which you don't want to hear. So if you want to block ads from, to choose just one of many entertaining entries in my own hosts file, fleshlightcash.com (sadly, that domain is now parked; I would appear to have missed my opportunity to make cash with fleshlights), you'd put a line in hosts that says:
Now any attempt to access that domain will instantly go nowhere and fail. (www.fleshlightcash.com will still resolve, though; you'll need to separately block that, and any other subdomain permutations of the address, if they exist. This also means you can block subdomains without blocking the "main" domain, so you could for instance not put an entry in your hosts file for www.SomeSiteWithAnnoyingAds.com, and block ads.SomeSiteWithAnnoyingAds.com, if that site obligingly served its annoying ads from the "ads" subdomain.)
It's still possible for a 127.0.0.1'd domain to resolve if it's still in your local DNS cache. In Windows, you can make sure any changes to the hosts file are working by typing "ipconfig /flushdns" in a command-line window.
And yes, you can mess stuff up if you accidentally send, say, microsoft.com or google.com requests to the bit bucket by blocking them in hosts. But it's easy to fix that mistake, by just removing the relevant lines from the hosts file.
If you're now wondering whether you can also use the hosts file to redirect all google.com requests to, oh, something like fleshlightcash.com: Yes, you can do that too.
Though people don't often do that to their own computers.
Could be worse. Could have that little animated dog.
I recently switched to Win7. I like it well enough except for one thing.
I LOATHE the alleged search.
In XP, I could open the search window and type the part of the filename I could remember, along with the drive I think it's on. C:\*.foo and away it goes. In 7, as far as I can tell, if you don't already know where the file is, don't bother even trying to search for it.
Is there any way to un-horrible the Win7 search? I've tried a couple of things that claimed to fix it, Agent Ransack and... another one whose name I can't remember and can't now find on the list. Both of them appeared to be just different skins for the same lousy search.
I haven't got a proper answer for you here, because there are several reasons why crap like this can happen. The standard indexed search may not be as useful as you'd think it'd be, but it at least shouldn't slow the computer down noticeably. If the search indexer scans tons of files on a hard drive while something else is also flogging the drive then there'll be a nasty performance hit, but Windows is actually pretty good at spotting when the indexer shouldn't be running. (This problem is also greatly reduced if you have a solid-state drive, which'll have seek speed close to zero.)
Pending a real answer, though, get "Everything".
Everything is an instant filename search for NTFS drives. No content search, just filenames. It's surprising how often that's good enough, though - both for finding data files, and for running programs!