New here, and my apologies if this has been addressed elsewhere definitively, but I am at a loss after quite a bit of research.

 

Am configuring a clean install of Unraid 7.0.0 beta-2 on a UGreen DXP480T Plus NAS, which is all NVME storage. Presently, of the four NVME slots, three are in use (all 4TB).

 

I am looking for guidance on best practices for configuration/utilization of these NVME disks. Given that this is all NVME, I am wondering about the necessity of creating a cache. I believe, from what I have been reading, that Unraid 7 (possibly) presents a new path forward in this regard, and that some of what I have read about disk allocation (particularly with respect to all NVME configurations) in prior Unraid versions may no longer hold.

 

Would be most grateful for input on best practices for how to approach configuration of this clean install of unraid 7.0.0 beta-2.

 

Many thanks.

I would recommend using a single raidz zfs pool, though note that you won't be able to expand with a 4th device later, at least not for now.

@JorgeB

 

Many thanks. Perhaps I could add a follow-up question:

 

How would you weigh the relative merits of creating a single array (two data, one parity) vs. creating a raidz zfs pool?

The raidz would be much better performance wise. but an Unraid style array is easier from an expansion viewpoint.  
 

There is also the fact that in disaster scenarios with an Unraid array each drive is a free-standing file system so if you lose more drives than you have for parity only the failed drives content is lost whereas with a raidZ array you would lose everything.

 

Super helpful, thank you. My intuition is that given the expected level of usage (e.g., demand on the drives) and the general performance benefit of NVME, that the ease of expansion and free-standing nvme recovery benefits of the Unraid array path is of greater value than the performance pickup in raidz. Does this sound right?

And one additional question: do you have any insight on possible TRIM-related concerns with having the all-NVME array? Again, thank you.

TRIM won't work in the array, but if performance is not a concern it can still be a good option.

As I have been going further down the reading rabbit hole, the concern I am zeroing in on the issue of the NVME controller (in my case, Samsung 990 Pro) running trim functions independently, and this causing issues for the parity process in the array. Am I thinking about this correctly? Grateful for your insights.

And, I suppose, alternatively, if I should take the pool route and select the "none" option for array in Beta-2, and I create a pool with raid-z1, what would be the limitation if I elect to add a fourth NVME to the storage pool at a later date? If I did so, it would be a NVME matching the three currently in line (e.g., 4TB).

18 minutes ago, OMedia said:

running trim functions independently, and this causing issues for the parity process in the array.

AFAIK it doesn't do trimming, just garbage collection, and that should be fine with parity, but any issues would also be apparent after you run the first parity check.

 

14 minutes ago, OMedia said:

what would be the limitation if I elect to add a fourth NVME to the storage pool at a later date?

As mentioned you won't be able to use it to expand an existing raidz pool

29 minutes ago, OMedia said:

issue of the NVME controller (in my case, Samsung 990 Pro) running trim functions independently

That is not a thing, if it was it would just randomly lose data.

The drive cannot know what is useful data and what is not so it always has to preserve state. That's why TRIM exists, so the system can let it know what it's allowed to discard.