SSD Array for unraid?


Recommended Posts

I have a couple used ssd’s, out of curiosity, can I build an array with parity with it?, don’t have an unraid system built yet, still learning as much as I could about it, don’t need any mass storage, just fast access to files. What are the pros and cons aside from the cost (obviously). Do mechanical drives last longer with parity? Or ssd are still superior in this case?

 

 

Sent from my iPhone using Tapatalk

Link to comment

Samsung announced this week mass production of consumer level 4TB SSDs.  Whilst the prices aren't known yet (to me at least), it got me thinking again about a supported version of unRaid running on SSDs.

 

I'd quite happily shift over to something running quieter, faster, smaller and more efficient at some point.

 

Does anybody know the latest on Lime Tech officially supporting/recommending SSDs in the array?  Or does the TRIM rule it out completely?

  • Like 1
Link to comment
24 minutes ago, Cessquill said:

Or does the TRIM rule it out completely?

 

Some TRIM performs like zeroing - so a RAID machine can recompute the parity as if the data was zeroed (which means all disks needs to be online or the original contents needs to be read before TRIM is sent).

 

But the parity drive can never make use of TRIM, since it doesn't have a file system with unused portions to TRIM. This means that a RAID should be designed in a way where TRIM isn't needed for it to work well.

 

So the way to use SSD in a RAID is to have overprovisioning. Either enterprise disks that is delivered with a significantly large, hidden, amount of overprovisioning. Or high-end customer drives that can be configured so parts of the user space of the drive is reserved for overprovisioning.

 

But note that large HDD (especially helium-filled models) are quite efficient when used for a home media server, since you can often manage with a single disk spinning. So best is a tiered solution where data files and audio is stored on SSD and movies and TV-series are stored on big HDD. This is what I am currently doing. So mirrored SSD for often used data. Mirrored 2.5" HDD for next tier of data. And then multi-disk RAID with dual-parity for bulk storage. And backup to drives that are allowed to spin down between each backup run, with new data "rolling" over multiple drives so backup drives doesn't need to spin up every night.

  • Like 2
Link to comment
  • 9 months later...

They've landed now.  In stock (note it's NZ price) as per links below.  The 8TB might be out of my price range though.

 

https://www.pbtech.co.nz/product/HDDSAM60400/Samsung-860-QVO-MZ-76Q4T0BW-4TB--Samsung-V-NAND-SA

https://www.pbtech.co.nz/product/HDDITX45108002/Intel-P4510-Series-8TB-25-PCI-E-NVMe-SSD-3200MBs-r

 

Without reading up on it (so could be wrong), the below statement in 6.7.0 release almost sounds like it would work for a filesystem across multiple ssd's?

 

Added the '--allow-discards' option to LUKS open.  This should only have any effect when using encrypted Cache device/pool with SSD devices.  It allows a file system to notice if underlying device supports TRIM and if so, passes TRIM commands down.

 

?

Link to comment
  • 1 month later...

Not trivial at all when you can't guarantee how the SSDs behave when a "trim" command is sent to them. Taking the disk offline, trimming it, and putting it back online can Frak up your Parity protection.

Edited by BRiT
  • Upvote 1
Link to comment
26 minutes ago, fluisterben said:

Does seem somewhat trivial to also support it for array devices. Just take the disk offline, trim it, put it back online.

Keep in mind that parity is calculated and maintained for every bit, not just the bits actively used by files. If you change bits in an "unused" area with the drive offline, that parity address will be wrong when you put the drive back in.

Link to comment

Yup, and all that has to be supported by the unRAID md block driver as specified by the requirements on the link you posted. So it's not trivial as you think.

 

Requirements

  1. The block device underneath the filesystem must support the FITRIM operation.
Link to comment
  • 1 month later...
On 7/13/2019 at 8:46 PM, BRiT said:

Yup, and all that has to be supported by the unRAID md block driver as specified by the requirements on the link you posted. So it's not trivial as you think.

 

Requirements

  1. The block device underneath the filesystem must support the FITRIM operation.

"All that" ? Looks to me like a little config editing and you're done. Seriously, it's 2019 and Unraid does not support TRIM in its array? This should at the very least be mentioned before trying to sell it.

Link to comment
18 minutes ago, fluisterben said:

You need to grow up and stop yelling like a toddler. And mind your own business.

http://xfs.org/index.php/FITRIM/discard > "The kernel must include TRIM support and XFS must include FITRIM support (this has been true for Linux since v2.6.38, Jan 18 2011)"

You need to stuff your ignorance back up your backside. This aint Trump's states.

 

It has nothing to do with the config. The issue is how that would interact of parity calculation and there have already been reports of a certain SSD causing parity error when in the array - and that is without trim complicating the matter.

 

And for a double dose of stuffing ignorance back up your backside, I already raised a feature request to enable trim in the array before your throwing tantrum. So I am minding my business.

 

Link to comment
"All that" ? Looks to me like a little config editing and you're done. Seriously, it's 2019 and Unraid does not support TRIM in its array? This should at the very least be mentioned before trying to sell it.
Tom answered this question in the Q&A only certain SSDs are possible to use. And it's all dependent upon what they return for a sector contents after either a trim or background garbage collection. Since not all SSDs handle this the way that any RAID system needs it to then you just cant say you support SSDs. The ones which handle it correctly though will operate no problems.

If they dont handle it correctly then on any RAID system you will wind up corrupting the parity system

Sent from my NSA monitored device

Link to comment
  • 2 weeks later...
On 9/9/2019 at 9:47 AM, Squid said:

Tom answered this question in the Q&A only certain SSDs are possible to use.

Now you've got me curious on which ones might work... but I can't find the thread. If you could post a link, search terms, or point me to where this topic is, that would be great. Thanks!

Link to comment
  • 1 month later...
  • 1 month later...
On 10/27/2019 at 9:16 PM, gareth_iowc said:

i've been running a 3 drive ssd array for about a year now with no trouble.

 

I don't yet have a parity drive and was thinking of adding an ssd one.

 

Anyone successfully using ssd as parity?

I am sick and tired of dumping north of 300 bucks on replacement hard drives which regularly fail after 2 years (despite being enterprise seagate ones). Since my data hoarding is mild (< 1TB) I am going to wing it and simply spin up 4x500GB SSDs array without parity until official support lands. Even if trim is disabled I think I'll survive for plenty of years (don't remember the last time I actually deleted something from the array, for frequent changing data I rely on SSD cache drives anyway).

 

The reason I'm doing this is purely out of longevity issues with mechanical drives and the specific use I make of my storage space. As for parity, well I'm going to risk it, based on the fact that in > 8 years of SSD usage I had zero bit rot and zero failures.

 

So, thanks for confirming that you had no trouble with an SSD array without parity, that's all the reassurance I needed to get rid of the anxiety of expensive mechanical drives failing on me yet again!

Link to comment

You can have parity, of all the SSDs I tested only one had a couple of regular sync errors, the now descontinued Kingston SV300, I also have a small all SSD array with parity mostly for testing and without any issues.

 

If using parity I recommend getting a faster SSD, more endurance will also be a plus, remember that parity will have many more writes than any other data device and even if/when LT adds trim support parity can never be trimmed, since it doesn't have a filesystem, I'm using one WD NVMe black for parity and 4 SATA WD Blue 3D devices for data, and I'm getting good performance so far, I'll see after a few months how the lack of trim degrades performance.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.