How-To Geek
6 Things You Shouldn’t Do With Solid-State Drives

Solid-state drives are different from the mechanical, magnetic hard drives in wide use. Many of the things you’ve done with typical mechanical hard drives shouldn’t be done with newer solid-state drives.
Solid-state drives are presented by the operating system the same way mechanical drives are, but they work differently. If you’re a geek, knowing what you shouldn’t do is important.
Don’t Defragment
You shouldn’t defragment solid-state drives. The storage sectors on an SSD have a limited number of writes — often fewer writes on cheaper drives — and defragmenting will result in many more writes as your defragmenter moves files around.
What’s more, you won’t see any speed improvements from defragmenting. On a mechanical hard drive, defragmenting is beneficial because the drive’s head has to move over the magnetic platter to read the data. If a file’s data is spread out over the drive, the head will have to move around to read all the little pieces of the file, and this will take longer than reading the data from a single location on the drive.
On a solid-state drive, there’s no mechanical movement. The drive can simply read the data from whatever sectors it resides in. Solid-state drives are actually designed to spread data around the drive evenly, which helps to spread out the wear effect — rather than one area of the drive seeing all the writes and getting worn down, the data and write operations are spread over the drive.

Don’t Wipe
Assuming you use an operating system that supports TRIM — Windows 7+, Mac OS X 10.6.8+ , or a Linux distribution released in the past three or four years (Linux kernel 2.6.28+) — you never need to overwrite or “wipe” your free sectors. This is important when dealing with mechanical hard drives, as files that are deleted on mechanical hard drives aren’t actually deleted immediately. Their sectors are marked as deleted, but until they’re overwritten, the data could be recovered with a file-recovery tool like Recuva.
To prevent this from happening when disposing of a PC or hard drive, people use tools like DBAN or the Drive Wiper tool in CCleaner to overwrite the free space, ensuring it’s full of unusable data.
On operating systems that support TRIM, files are deleted immediately. When you delete a file in your operating system, the OS informs the solid-state drive that the file was deleted with the TRIM command, and its sectors are immediately erased. Your data will be deleted immediately and can’t be recovered.
Some old SSDs don’t support TRIM. However, TRIM was added shortly after SSDs hit the market. Unless you have a very early SSD, your drive should support TRIM.

Don’t Use Windows XP, Windows Vista, or Disable TRIM
If your computer is using a solid-state drive, it should be using a modern operating system. In particular, this means you shouldn’t use Windows XP or Windows Vista. Both of these old operating systems do not include support for the TRIM command. When you delete a file on your hard drive, the operating system can’t send the TRIM command to the drive, so the file’s data will remain in those sectors on the drive.
In addition to allowing for theoretical recovery of your private data, this will slow things down. When your operating system tries to write a new file to that free space, the sectors must first be erased, then written to. This makes file-write operations take longer and will slow down your drive’s write performance.
This is also why you shouldn’t disable TRIM on Windows 7 and other modern operating systems. It’s enabled by default — leave it that way.

Don’t Fill Them to Capacity
You should leave some free space on your solid-state drive or its write performance will slow down dramatically. This may be surprising, but it’s actually fairly simple to understand.
When an SSD has a lot of free space, it has a lot of empty blocks. When you go to write a file, it writes that file’s data into the empty blocks.
When an SSD has little free space, it has a lot of partially filled blocks. When you go to write a file, it will have to read the partially filled block into its cache, modify the partially-filled block with the new data, and then write it back to the hard drive. This will need to happen with every block the file must be written to.
In other words, writing to an empty block is fairly quick, but writing to a partially-filled block involves reading the partially-filled block, modifying its value, and then writing it back. Repeat this many, many times for each file you write to the drive as the file will likely consume many blocks.
As a result of its benchmarks, Anandtech recommends that you “plan on using only about 75% of its capacity if you want a good balance between performance consistency and capacity.” In other words, set aside 25% of your drive and don’t write to it. Only use up to 75% of your drive’s free space and you should maintain ideal performance. You’ll see write performance start to slow down as you go above that mark.

Don’t Write Constantly To Them
To increase your SSD’s life, you should try to minimize writing to the drive as much as possible. For example, you can do this by tweaking your program’s settings and having them write their temporary files and logs elsewhere, such as to a mechanical hard drive if you have a mechanical hard drive in your computer.
Tweaking such application settings will be going overboard for most users, who shouldn’t have to worry about this. However, you should nevertheless bear this in mind — don’t run applications that have to write temporary files to the drive constantly. If you do use such applications, you may want to point them at a mechanical hard drive where you won’t have to worry about the drive being worn down.
Don’t Store Large, Infrequently Accessed Files
This one is fairly obvious. Solid-state drives are smaller and much more expensive per-gigabyte than mechanical hard drives are. However, they make up for it with reduced power consumption, less noise, and increased speed.
Ideal files to store on your solid-state drives include your operating system files, programs, games, and other files that must be accessed frequently and quickly. It’s a bad idea to store your media collection on a solid-state drive, as the speed isn’t necessary and you’ll use up much of your precious space. If you don’t have enough space on your SSD, store your large media collection on a mechanical hard drive. If you use a laptop, consider getting an external hard drive for your media. Mechanical hard drives are still very good at providing a very large amount of storage at a low cost per-gigabyte.

Image Credit: Yutaka Tsutano on Flickr, Basheem on Flickr (modified), TAKA@P.P.R.S on Flickr, Norlando Pobre on Flickr
Great list of things not to do. Even for someone like myself in IT, I tend to forget that I should, if capable, alter where programs write their log files etc. It's just something you tend to overlook on any given day.
God one
. The best part of the site is that even a noob can understand the language in which the article is written ![:blush: blush]()
The first laptop I bought with SSD was the Vaio VGN TT190 running Vista. I still use it occasionally, when I need 2 laptops running side by side. The SSD is quite full and, despite those 2 "don't do" everything is still running smoohly although yes, it is now quite sloooow (at least compared to the new Vaio).
Regarding wiping SSDs, what's the best alternative to DBAN? We're required by our corporate office to wipe old hard drives before retiring computers, doing at least a 3-pass wipe to remove all data and the OS. If you can't use DBAN to do that, what should you use?
http://www.kingston.com/us/community/articledetail/articleid/10
It seems that HDDerase is suffice. See article above.
How about the "page file". Should we leave this on in a SSD?
What are some examples of programs that heavily write temporary files?
so generally you should not use it. why? because most of the topics you show will make it useless. you generally buy SSD because of its speed. which depends on frequent read and write of your application
I was under the (mis?)impression that Windows 7 defragged drives in the background. Is this false? If not, is Windows 7 smart enough not to defragment SSDs? If not, can the background defragging be turned off?
@mathewsdaniel3 I've seen it enabled on SSDs more often than not. Go to the Start menu and click on “All Programs”, “Accessories”, “System Tools” and “Disk Defragmenter”. Go to “Turn off schedule” and make sure that Windows does not defragment your SSD drive
I think it depends on how Windows was installed. If you do a vanilla install, straight from the disk, Win7 has it enabled by default. However, OEM manufacturers usually (not always) turn it off.
I bought a Lenovo Yoga with a 128GB SSD, and check defrag was the first thing I did when I turned it on. Thankfully, it was already off.
I think you've clearly hit a vein here, HTG, and a lot of completely understandable ignorance and misconception is going to surface as a result. Maybe another article could expand on the "six things" idea and explain why (and how) avoiding the six things doesn't devalue SSDs for either geeks or average users. You left one goodie out, though: Indexing should definitely be disabled on the SSD, because it involves a great deal of reading and writing with absolutely no benefit. The SSD already accesses all files as rapidly as it can. Having an index to refer to might even actually slow down SSD searches, rather than speed them up.
Agree strongly, Indexing on an SSD is not needed on a disk that seek time is non-existent because we don't have to wait for platters to spin up and get to the desired location after finding the file within the mft. You can still have indexing, if you still use windows indexing service, for other mechanical storage drives you may have installed.
Indexing is not because of slower seek time. It is for "Finding" files quick. If I search for a file which contains "my project name", without indexing, every file in the disk needs to be searched. If it is indexed, it can be found from the index in a matter of seconds.
Indexing doesn't require too much writing. And a lot of reading of SSD is not a problem. Only writing can wear out SSD.
So why change to an SS?. Seems not worth the bother after all. The beauty of a computer is its retrieval system. If this ease and convenience is lost with all the caveats of an SSD, then the computer's retrieval system becomes less functional. And while on the topic of retrieval--Windows 8 presents something of a learning curve. Material in Windows 7 that was automatically saved to 'my documents' now ends up--well, God knows where. I have to search around before I can find the PDF that I downloaded and have to use many times before I'm done with an assignment. Retrieval works best when the system is clear and easily comprehensible.
Does this apply to virtualized (hyper-v, VirtualBox, etc) instances that are HOSTED on SSD drives, as well?Are you also saying we shouldn't run XP VMs on newer SSD Win8 machines (Surface pro?), even if we want full compatibility with older programs/games?
The SSD Optimization Guide Redesigned (6 Pages) Numbered at the Bottom of Page
http://thessdreview.com/ssd-guides/optimization-guides/the-ssd-optimization-guide-2/
How to Reset SSD back to Factory Condition.
http://howto.cnet.com/8301-11310_39-20115106-285/how-to-securely-erase-an-ssd-drive/
http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml (Requires Hot Plugging SSD)
Just checked mine as I assumed it would be off by default, but it has been doing a weekly defrag for the last couple of months, since this PC was commissioned. I bought it complete without OS and installed an SSD then installed Win 7 64 bit straight to the SSD, yet it still enabled scheduled defrag, so don't assume it is off. Also just checked indexing and it was on as well, windows really should be smarter than that, but obviously these have to be checked for new installs as you can't assume windows gets it right.
How about torrenting?
No issues which I've heard of.
Generally, an interesting article, but the section under 'Don't Wipe' is/could be confusing:To start with, your heading is "don't Wipe" but your illustration is of a program which does just that.Next, in the wording, you say: "When you delete a file in your operating system, the OS informs the solid-state drive that the file was deleted with the TRIM command, and its sectors are immediately erased. Your data will be deleted immediately and can’t be recovered."...but is that really what you mean........I'm thinking of inexperienced people here....do you mean when you delete a file using 'shift/delete' or 'empty the recycle bin', the file is 'unrecoverably' deleted, surely when you simply delete a file, it is merely added to the recycle bin, not lost forever? Next Again: Shouldn't the whole wording from: "This is important ....to....ensuring it’s full of unusable data." be treated as a separate issue. The very presence of the 2nd. paragraph is misleading in the context of this article. IMHOAussiegreg2
I think @AussieGreg2 has a point for complete neebies.But, on the other hand, anyone interested enough to start looking at the workings of the SSD's will probably have enough background to follow the logic of the article and understand.
I think this is another one I liked.
Regarding filling it up to capacity, would it work to create a 25% size partition and keep that clean? Or am I being ridiculous?
A really good site to find out about SSDs.http://thessdreview.com/Forums/ssd-beginners-guide-discussion/
It shouldn't because those have their own Virtual Hard Drives so they won't be deleting files from that anyways, they will delete files from their virtual disk.
@andrewrobert7: That's what I figured. (I checked later and on the host, the virtual machine's VHD appears as one big file.)
What about network shared folders hosted on a SSD, but possibly accessed by someone else's XP machine?Or what about host folders shared/mounted with a XP VM on the host's SSD? (VirtualBox has such an option)
Does this apply to virtualized (hyper-v, VirtualBox, etc) instances that are HOSTED on SSD drives, as well? Are you also saying we shouldn't run XP VMs on newer SSD Win8 machines (Surface pro?), even if we want full compatibility with older programs/games?
You raise some interesting questions. It's really pretty simple though: The only OS that can possibly delete a file from an SSD (which is the only time TRIM comes into play) is the one running on the motherboard that the SSD is physically connected to...as that's the only OS that has drivers that can talk to that drive. Only that OS needs to support TRIM.
Shared folders are fine regardless of the OS on the clients, whether they're networked or are a VM running on the host OS. When a computer is writing/deleting to a shared folder, it isn't actually making changes directly to the SSD. Rather, it's sending the change requests to the host OS, and the host OS then makes those changes to the SSD. If the operation was a delete, the host OS deletes the file record from the file allocation table, then sends a TRIM command to the SSD that lets it know what sectors are now available for blind overwrite.
Same thing with a VM that stores its files on the host, the host is actually doing all of the file access for the VM. That's the whole point of a VM, it thinks it's a physical computer with physical drives, but it's not. Only the actual physical computer can make changes to the SSD.
Of course, this applies to all kinds of disks. The VM client OS or network client OS has no idea whether it's writing to an SSD, a RAID array, a hard disk, a RAM disk, a floppy disk, a memory card or whatever, or if the host file system is NTFS, FAT-32, FAT-16, FAT-12, exFAT or something else. A DOS 6.22 client can use a share on an NTFS drive, even though it has no idea what NTFS is (though make sure there isn't more than 2GB of free space on the partition or more than 512 files in the root of the share, or it'll lose it's little DOS mind.) All that the client really needs to know is the most basic of information, like how many bytes are free on that volume and a list of the files that are there. Everything else is masked through the magic of file sharing by the host OS.
I apologize, Lady Fitzgerald, for communicating vaguely. My use of the word "actually" was meant to say "by combining file blocks together, defragging causes congestion in data access. I did NOT mean "actually" to say 'this is actually the one and only real problem with defragging'. I apologize for being unclear. I'm well aware that SSD's are damaged by excessive writing, and I make sure to turn off defrag first thing.
The part about the memory pathways comes from a relative who works in that department of Intel. We had the discussion after our accountant's laptop Intel SSD died. Unlike HDD's that get noticably slower, this one failed instantly without warning, and his department at Intel was extremely interested in getting that drive back for an autopsy. I had a long chat with him about how they worked, and he described to me the multiple memory pathway thing, and how fragmented files were much better for both speed and error correction, since spread out files had less loss in tiny failures that checksums had a better chance of invisibly fixing.
Also, he mentioned how larger SSD's are faster, because they have more of those memory pathways to use simultaneously.
By coincidence my OCZ Agility 60 gig just filed it's retirement papers due to overwork, SMART showed imminent failure due to 'old age'. Windows 7 was popping up warnings every 5 minutes saying 'back up now, you're about to lose everything'. Though the previous posts were written on a Win7 PC with the OCZ, this post is brought to you courtesy of Ubuntu 13.04 on a Samsung 840.
It's the 9th SSD I've installed in various PC's in the last year, and the first to replace another SSD. (Accountant took care of her own)
Valid points, crank. I erred on several counts. I never, ever search for content, though,so giving my SSD an index to consult (a content-full index, that is) rather than just the filename list might just make my searches slower.
And yes, storing the index on an HDD instead of on the SSD is a great idea. Apparently, you can move the index anywhere by going to Indexing Options | Advanced, and typing in the new location. Haven't tried it cuz I have no index to move.
Thanks for your contribution.
I've had this discussion before, and the conclusion was that the safest thing to do is to destroy any Flash media.
However, SSD's do typically have a "secure erase" command. You need to find out if your drives do, and if they do - how you can activate it. (There should be a utility you can run.)
Do some Google searching for "Sanitize Flash Media"... there's a treasure trove of info out there. Here's one example: https://www.usenix.org/legacy/events/fast11/tech/full_papers/Wei.pdf