3

From what I've been able to understand when reading about the case with Solid State drives and raids, the problem is that TRIM cannot be used for them in a raid configuration, thus, resulting in the disks becoming slower over time when files are deleted.

A use case I currently am considering is using SSD:s in a raid storing a database without deletions, just read and write operations are performed.

Would this bypass the common problem of not being able to use TRIM when running raided SSD:s, or would other (supposedly related to how the database manages the data) surface?

Update: something worth mentioning regarding why I started to think of the viability of doing something like this is due to that these stack exchange sites seem to have been using SSDs for their storage for a while (http://blog.serverfault.com/post/our-storage-decision/)

  • The big 'problem' most of us have seen with SSDs is that they're easily killed by high write-environments. Otherwise they tend to work fairly well. See Jeff's [blog regarding Crazy/Hot SSDs](http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html). – Chris S Sep 27 '11 at 12:40
  • Thanks for the tip; didn't know that SSDs fails that often – Aron Lander Sep 28 '11 at 13:13

3 Answers3

7

Writes with SSDs are a bit of a Red Herring

Compared to traditional disk, dollar per IO is going to be much better regardless of TRIM given a random and not sequential pattern (and eventually IO activity seems to always become random). Although write heavy environments combined with SSDs and TRIM support is a concern, I think it is a bit of a red herring. I would shift your attention to reliability. This is because lots of SSD failures, from what I have seen, happen before writes should be killing drives. This could be firmware edge cases, problems with the chips. For Example, recently:

enter image description here

You could geek out with SSD and storage experts for days on the topic, but what it comes down to is that SSDs are still a relatively new technology -- not bleeding edge, but new. The technology is evolving quickly, which means that there really isn't much data yet on the failure rate. By the time there is data, you are already on the next generation. Also some other parts of the stack such as filesystems and disk schedulers might not be perfected yet when it comes to SSDs.

Tom's Hardware did a pretty good study on SSD reliability and concluded:

"The only definitive conclusion we can reach right now is that you should take any claim of reliability from an SSD vendor with a grain of salt."

So what most people are doing is just guessing.

Ultra-Violence

This means that SSDs are for the courageous, if you are not capable of using storage in Ultra-Violence or Nightmare! mode, you should stay likely stay with disk. As always, the technology should reflect the business -- at Stack Exchange we went with SSDs because we are performance junkies and don't need the uptime / risk mitigation of a global bank. So, if you do decide to use them, what does this mean to a sysadmin?

  • Have cold spares. Have replacement drives in your rack ready to replace drives (one nice thing about SSDs is a nice rebuild rate)
  • Monitor all your arrays. You should get alerts as soon as a drive fails
  • Have a lot of redundancy set up and be prepared for failure
  • Make sure your backups are working

In the end just be aware of what you are getting into, and be prepared. The performance is going to kick ass from my experience with or without trim. Since we have had those SSDs in our DB server around that time of the blog post (Raid 10 6 disks), here is what performance looks like for us today without TRIM and with 100-800 Transfer/s:

enter image description here

enter image description here

Kyle Brandt
  • 82,107
  • 71
  • 302
  • 444
  • Also, we haven't seen one of our SSDs in our Datacenter fail yet, but that blog post is still pretty recent. – Kyle Brandt Sep 28 '11 at 14:01
  • Thanks! This really answered what I needed to know; also, this does confirm some of my previous fears regarding the reliability of SSDs (most of my colleagues have just disregarded it as an issue occurring on the early SSD models). – Aron Lander Sep 28 '11 at 16:15
2

Remember that updates to existing data are also effectively "deletes" at the SSD layer. A new block needs to be written by the flash translation layer, and the old one garbage collected. Does your application do updates to existing data? (If you are running a database, even simple insertions into an indexed table also update one or more of the B-tree index pages!)

I would suggest choosing SSDs designed for higher-write workloads, such as the Intel 510 series or even better (and more expensive) the new 710 series. I would stay away from SLC-based SSDs simply based on extreme cost, and stay away from desktop-oriented "cheap" SSDs because they don't have much of a write reserve (and also often have buggy controllers and firmware).

rmalayter
  • 3,744
  • 19
  • 27
  • Going to perform almost entirely just inserts. The cause to why I mentioned that it was going to store a database was indeed due to that I suspected that the database might do some additional "file handling magic". – Aron Lander Sep 28 '11 at 13:16
1

If you have the money for them, even degraded SSD's due to no TRIM maintenance should outperform regular drives, and by the time it would be a real issue you should be nearing the point of your hardware cycle when they'll need to be cycled out with upgraded servers/hardware anyway.

In some cases as @ChrisS said you'll end up replacing some of the drives due to wear/failure anyway in the RAID array, so you'll bump up the counter on their lack of TRIM maintenance anyway.

If TPTB are willing to fund a superfast RAID server with SSD drives, go for it, budget appropriately for maintenance/replacement down the road. I don't think a few percent degradation will be all that noticeable after network I/O bottlenecks and CPU bottlenecks are figured in and the overall performance boost will still be greater than you would have otherwise.

Bart Silverstrim
  • 31,092
  • 9
  • 65
  • 87