Pool layout for Plex streaming

Hi!

Long time listener, first time caller. First, thank you all for this amazing community and all the great things I’ve learned reading here.

Second, let me apologize for yet another pool/vdev layout question. I haven’t seen an answer to my specific scenario in other posts. I have read a lot before posting this (including the ixsystems whitepaper on pool layout).

Use case: Essentially my pool will be used for Plex content streaming (and backups for a few of my other machines). I’m replacing a 80tb Drivepool / Snapraid windows system with a new TrueNas Scale system with 12 x 18tb drives using a 10 GbE network. TrueNas will only be the NAS itself, I have a separate SFF box for the Plex server (so no VMs on the NAS). I sometimes see 15 concurrent streams but would like to plan for 20 in the future. Generally this is three 4k streams maximum with the rest being 1080p. My old windows system will be used as a full backup for the new pool.

Based on the use case, I think my priorities should be: 1) capacity, 2) resilience, 3) performance in that order.

To me the two logical layouts are:

  • 1 wide vdev in RaidZ3 - Significant capacity, significant resilience, maximum bandwidth
  • 2 vdevs in RaidZ2 - Less capacity, significant resilience, significant bandwidth, increased IOPS

I’m leaning towards the 1 wide vdev because of the increased capacity (and the theoretical bonus of easy vdev expansion in later versions of truenas). I don’t think IOPS really matters in my scenario but please feel free to argue with me or propose other layouts.

Really just wanted a sanity check from you experts before I pull the trigger on this fairly major decision.

Thanks in advance for any insights or thoughts you may have!

1 Like

Twelve disks is about as wide as you’d want to go in a vdev, so I wouldn’t count on that.

Other than that, between the two proposals, I’d say it’s close to a toss-up. But lots of simultaneous clients might result in a greater IOPS load than you’re anticipating.

2 Likes

Thank you! Makes complete sense.

I think I’d rather do the safe-than-sorry approach so based on your input will go with the 2-vdevs which increases the IOPS and would still allow for (later theoretically) expansion (but would require two drives at a time).

Id suggest the two vdevs. Will double your IOPS.

And with that many concurrent streams… iops may matter.

You may want to consider some metadata special vdevs too.

Also, you may want to consider 1MB block sizes on your dataset.

1 Like

Really appreciate the input. Makes sense. Will go with the 2 vdevs and definitely the 1MB block size.

I’ll look into the metadata special vdevs too. I had ruled them out based on previous research but I’ll do some more reading there for sure.

Thank you!