SSD Array for unraid?


Recommended Posts

On 12/17/2019 at 7:19 AM, johnnie.black said:

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.

I've wanted to ask if you've done any testing with a 4T or higher SSD, and how did it turned out? Any SSD's you would recommend for Parity? I appear to have a bottleneck on my parity drive and may need to upgrade to a faster drive, but if an SSD would safely work without issues I'll go with that.

Link to comment
5 minutes ago, XiuzSu said:

I've wanted to ask if you've done any testing with a 4T or higher SSD, and how did it turned out?

Not me but there are some post of users with 4TB parity, IIRC there's one with like 16 4TB SSDs.

 

For parity you want an SSD with good performance and high endurance, since parity can never be trimmed, even when LT adds trim support for the array, also it will have to endure much more writes than the array devices, I would recommend a good NVMe device or an enterprise level SSD.

  • Thanks 1
Link to comment
  • 5 months later...
On 6/25/2020 at 4:19 PM, JorgeB said:

IIRC there's one with like 16 4TB SSDs.

As far I understand the TRIM process it fully depends on the SSD controller if ti zeros the discarded sectors or not. Is there a way to find out if the SSD controller preserves the discarded sectors or zeros them?

 

And regarding the Parity: What about adding two parity disks and re-buidling the parity1 each odd month and re-buiding the parity2 every even month? By that you have for several hours each month only one parity protection, but the SSD is fully "trimmed".

Link to comment
28 minutes ago, JorgeB said:

for SATA

Ok, this is the interesting part:

Quote

 

There are different types of TRIM defined by SATA Words 69 and 169 returned from an ATA IDENTIFY DEVICE command:

 

Non-deterministic TRIM: Each read command to the logical block address (LBA) after a TRIM may return different data.

Deterministic TRIM (DRAT): All read commands to the LBA after a TRIM shall return the same data, or become determinate.

Deterministic Read Zero after TRIM (RZAT): All read commands to the LBA after a TRIM shall return zero.

 

As Unraids parity is sector based, we need DRAT. But what sends this ATA command?

 

fstrim calls FITRIM:

https://github.com/karelzak/util-linux/blob/master/sys-utils/fstrim.c

 

Quote

* This program uses FITRIM ioctl to discard parts or the whole filesystem
 * online (mounted). You can specify range (start and length) to be
 * discarded, or simply discard whole filesystem.

And as far as I was able to follow the functions called by FITRIM, it only sets the sectors to the status "discard" (it's ext4, but should be similar for XFS)

 

FITRIM:

https://code.woboq.org/linux/linux/fs/ext4/ioctl.c.html#991

 

Last nested function I found:

https://code.woboq.org/linux/linux/block/blk-lib.c.html#__blkdev_issue_discard

 

 

Link to comment

I would think RZAT is better. Then unRaid knows the data for that block of that drive should be set to 0 in its new parity calculation.

 

The verbiage of DRAT gives me moment to pause and ask WTF do they mean by "or become determinate". Does it return the original data, where unraid would do nothing to parity? Does it flip it to some other data like 255, where unraid would need to figure out what it does and then mirror the behavior to Parity? Or does it become a larger more complex pattern?

 

Quote

Deterministic TRIM (DRAT): All read commands to the LBA after a TRIM shall return the same data, or become determinate.

 

Link to comment

Sorry for hijacking the thread.

 

A couple of months ago i made our main computer into two gaming computers so me and the wife can play at the same time.

for my disposal i have an nvme drive (512GB), a sata ssd (256GB), and a couple of WD-red hdds (1TB) but i have yet to figure out the correct arrangement in the array to get maximum performance. Data loss is not critical.

 

could anyone maybe clear this up for me.

 

Thank you.

Link to comment
45 minutes ago, mgutt said:

With RZAT some sectors return 0 although they returned 1 before and so the Unraid parity, which was calculated with the 1, would be now incorrect. So this does not work. Or you must correct the parity in the same turn.

My thoughts are...

 

Any block device needs to listen for the TRIM commands and then act appropriately regardless of what the mode is, so no benefit on any of the different settings.

 

However, with RZAT/DZ_TRIM unraid would know that the block is now ZERO after the command is submitted.

 

With DRAT/DX_TRIM it is unknown what the new block value would be.

 

Quote

The SATA standard [14] leaves for the variant DX_TRIM open whether the returned data will be the same for different sectors or not.

Edited by BRiT
Quoting of DX_TRIM/DRAT unknown.
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.