SSD Array for unraid?

[Shinta0Saint 0]

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

[johnnie.black 1911]

You can, main disadvantage is that array devices can't be trimmed, so write performance might decrease over time.

[Shinta0Saint 0]

Thanks for the feedback much appreciated!


Sent from my iPhone using Tapatalk

[Cessquill 31]

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?

[pwm 214]

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.

[Cessquill 31]

Thanks for this - given me a lot to look into and think about.

[Marshalleq 13]

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.

 

?

[johnnie.black 1911]

5 hours ago, Marshalleq said:

the below statement in 6.7.0 release almost sounds like it would work for a filesystem across multiple ssd's?

Yes, for the cache pool, and trim always worked for the cache pool, it doesn't for array devices.

[fluisterben 1]

On 5/20/2019 at 9:38 AM, johnnie.black said:

Yes, for the cache pool, and trim always worked for the cache pool, it doesn't for array devices.

Does seem somewhat trivial to also support it for array devices. Just take the disk offline, trim it, put it back online. Samsung and WD's own SSD tools do this, keeping its contents alive and kicking.

[BRiT 148]

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 July 13 by BRiT

[jonathanm 587]

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.

[fluisterben 1]

3 hours ago, jonathanm said:

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.

http://xfs.org/index.php/FITRIM/discard

[BRiT 148]

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.