TODDLT Posted June 6, 2017 Share Posted June 6, 2017 (edited) I have a 500GB SSD I use for data in my parity protected array. (500 GB Samsung_SSD_850_EVO) I was just looking up info on using a cache pool and happen to read across this note in the official unRAID 6 documentation (not previously seen). Do not assign an SSD as a data/parity device. While unRAID won’t stop you from doing this, SSDs are only supported for use as cache devices due TRIM/discard and how it impacts parity protection. Using SSDs as data/parity devices is unsupported and may result in data loss at this time. How serious is this? Does anyone successfully use an SSD in their array? At this point I have replaced drives several times using the parity with this device in play. Any thoughts or advice is much appreciated. Edited June 6, 2017 by TODDLT Quote Link to comment
JonathanM Posted June 6, 2017 Share Posted June 6, 2017 For the most part data loss isn't the issue, performance is. You can't trim an array device, and writes are limited by the speed of the parity drive, so you lose almost all the advantages of the SSD over time as the SSD gets more and more fouled and needs a trim. Quote Link to comment
BRiT Posted June 6, 2017 Share Posted June 6, 2017 There might be parity corruption with SSDs depending on how it deals with garbage collection and TRIM commands. Somewhere in the forums is a lengthy discussion of this that covers all the theoretical aspects. Quote Link to comment
TODDLT Posted June 6, 2017 Author Share Posted June 6, 2017 8 minutes ago, jonathanm said: For the most part data loss isn't the issue, performance is. You can't trim an array device, and writes are limited by the speed of the parity drive, so you lose almost all the advantages of the SSD over time as the SSD gets more and more fouled and needs a trim. Not as worried about write performance. The data stored on the SSD is either data that I wanted faster access too (IE not waiting for spinup), or just much larger numbers of much smaller files that get re-written more often. The spinners are mostly media that is for the most part static. Quote Link to comment
TODDLT Posted June 6, 2017 Author Share Posted June 6, 2017 8 minutes ago, BRiT said: There might be parity corruption with SSDs depending on how it deals with garbage collection and TRIM commands. Somewhere in the forums is a lengthy discussion of this that covers all the theoretical aspects. Is there a list of drives that are OK and/or drives that are not? Quote Link to comment
JorgeB Posted June 6, 2017 Share Posted June 6, 2017 As should be fine, and as long as there are always 0 errors on parity checks you know you are OK. Quote Link to comment
garycase Posted June 6, 2017 Share Posted June 6, 2017 As Johnnie noted, as long as you're not seeing unusual parity errors, you're fine. The issue with some SSDs has been that since UnRAID does not support TRIM, if you run a TRIM command on the drive, some unused sectors may be zeroed without UnRAID "knowing" about this -- which can cause apparent parity errors on the next parity check. If this DID happen, it wouldn't really be a big deal as long as you're doing correcting checks -- the parity drive would be properly updated and all would still be well. The problem would be if it happened, but you didn't realize it (i.e. hadn't done a parity check); and then a drive failed, and you were doing a rebuild ... the rebuilt drive could be corrupted due to the incorrect bits from the SSD used as part of the rebuild. I do NOT think this is in general an issue at all -- especially if you either (a) don't run any manual TRIM utilities; or (b) if you do, that you immediately follow them with a correcting parity check. Johnnie probably has more experience with this than anyone on the forum, as he maintains an all-SSD array for a test bed ... and (I suspect he'll comment here) as far as I know he hasn't had any issues with this at all. 1 Quote Link to comment
JorgeB Posted June 6, 2017 Share Posted June 6, 2017 3 minutes ago, garycase said: don't run any manual TRIM utilities; Trim won't work on array devices, the only danger would be way the garbage collection works on a specific SSD, but as long as there are no errors on check it's fine. Quote Link to comment
HellDiverUK Posted June 6, 2017 Share Posted June 6, 2017 Most modern drives don't really need TRIM'ed. Quote Link to comment
TODDLT Posted June 6, 2017 Author Share Posted June 6, 2017 Thanks to everyone who responded. I can confirm I have never run a "Trim" command (obviously never heard of it) but it sounds like it won't run anyway. I've never once experienced a parity check error (knocks on the desk) so does that mean my drive likely doesn't have one of these "garbage collection" issues? I looked back and this drive has been in the array for what is approaching two years. I used to have a 2nd smaller SSD in the array as well and in all that time never saw a parity error. Is there a list of known good or bad drives? I was also considering adding a 2nd SSD to the array and a 2nd cache drive to start a pool (will be posting another thread about the pool, separate issue). Quote Link to comment
JorgeB Posted June 6, 2017 Share Posted June 6, 2017 1 minute ago, TODDLT said: Is there a list of known good or bad drives? I tested several different brands and models and the only one that I ever had unexpected sync errors was the Kingston SV300. Quote Link to comment
TODDLT Posted June 6, 2017 Author Share Posted June 6, 2017 1 minute ago, johnnie.black said: I tested several different brands and models and the only one that I ever had unexpected sync errors was the Kingston SV300. Thanks. I'd likely stick with Samsung or Mushkin if I were adding a drive. Were these included in your tests? Of course not asking for "guarantees" of anything, but based on your testing, do you trust SSD's in a production environment? Quote Link to comment
JorgeB Posted June 6, 2017 Share Posted June 6, 2017 2 minutes ago, TODDLT said: Were these included in your tests? Never had any issues with Samsung 830/840EVO/850EVO 3 minutes ago, TODDLT said: Of course not asking for "guarantees" of anything, but based on your testing, do you trust SSD's in a production environment? Yes, as long as there are no sync errors I believe you are as safe as with HDDs, probably more as SSDs are much less likely to fail. Quote Link to comment
TODDLT Posted June 6, 2017 Author Share Posted June 6, 2017 2 minutes ago, johnnie.black said: Never had any issues with Samsung 830/840EVO/850EVO Yes, as long as there are no sync errors I believe you are as safe as with HDDs, probably more as SSDs are much less likely to fail. How about Mushkin Advanced Reactor/Triactor/Chronos? When I look at the specs I see Silicone Motion and Sand Force listed as controllers, would that have any bearing on this issue? None of this applies to a cache pool, correct? Quote Link to comment
JorgeB Posted June 6, 2017 Share Posted June 6, 2017 Just now, TODDLT said: How about Mushkin Advanced Reactor/Triactor/Chronos? Never had any of those. 1 minute ago, TODDLT said: None of this applies to a cache pool, correct? Correct Quote Link to comment
thaddeussmith Posted June 19, 2017 Share Posted June 19, 2017 On 6/5/2017 at 10:23 PM, TODDLT said: Not as worried about write performance. The data stored on the SSD is either data that I wanted faster access too (IE not waiting for spinup), or just much larger numbers of much smaller files that get re-written more often. The spinners are mostly media that is for the most part static. Assign ssd to your cache, and then keep those files in a cache-only share. Quote Link to comment
garycase Posted June 19, 2017 Share Posted June 19, 2017 1 hour ago, thaddeussmith said: Assign ssd to your cache, and then keep those files in a cache-only share. This works, but unless the cache is a fault-tolerant btrfs array it won't be fault-tolerant, as it would be if the SSD was a member of the protected array. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.