10gig network, 5 drives.. what's best option...

[beowu!f]

So, I have a 16 core Threadripper server, 48GB RAM, boot/os is on a NVMe SSD (sadly a 512GB so most of it is lost). I have 5 16TB Exos HDDs.

Naturally I want the maximum storage space, while being redundant, which I think RAID6 handles? However, mostly I am storing ripped bluray 4K ATMOS HDR movies.. which will require a pretty beefy throughput to play over the home network. I don't think the 10gig matters here because the player that connects to home theater is on a 1gig connection. But I would like to maximize that 1gig speed as much as possible so as to avoid any hiccups when playing the 4K content.

That said, is RAID6 (zfs?) good enough to saturate the 1gig player end of the network.. I am sure my 10gig nic will easily handle the outbound from the server. OH..this will be using Plex server btw.. as a plugin I think to TrueNAS.

Also.. the m/b can handle 2 more NVMe SSDs. Would it be beneficial to put a 2nd one in for cache? I have a few 500GBs laying around not in use. I know you can reclaim most of the main boot SSD if you want (did it a year ago...) but at this point, I can live with the loss of the extra space TrueNAS wont use. Heck the SSD been sitting for 3 years unused.. so not even going to bother with the partitioning stuff I did last time I tried to play around with TrueNAS. But am wondering if the 2nd SSD will help in performance, etc since I can fit one in.

Thanks.

 

[Forza]

With RAID6 you loose 2/5 disks in space. Would RAID5 be enough? Otherwise I'd do spanned disks or raid0 with extra backups instead. Mostly streaming is sequential reading, så I doubt you would have performance issues in any case. Worse if you are going to transcode HDR->SDR. But the Threadripper might be fast enough for this?

 

[beowu!f]

Interesting.. RAID 6 primarily has one advantage.. you can withstand 2 drives dying. So RAID 5 stripes over all drives making reads fast.. but still is redundant enough for one drive to die, and rebuilding is fast. Seems to me since 95% of my data will be video data that I can recover in other manners should I lose it, and the likely hood of 2 drives dying at the same time is very slim, RAID 5 seems like the best choice.

I wasn't sure if TrueNAS has it's own special "RAID 5/6 like" option, similar to how Synology has it's own format that I thought I read was better than RAID5 alone? Can't remember now. I know in my 40TB Synology setup, I have around 30TBs of usable storage.

I am still unclear how Plex server handles transcodes. I thought the playback engine (e.g. Apple 4K Player) did the transcoding in real time (via the plex app). I am unclear how the plex app determines it needs to transcode on the fly. It seems to me transcoding when it is first added to the NAS would save on any real time transcode needs and playback should be smooth. I suspect I may be seeing transcode issues which would mean that even the latest 2021 4K Apple TV can't really play 4K HDR content very well.

I am hoping the nVidia Shield will have an update soon. It's over 3 years old now.. so thinking its worth it to just wait for updated hardware..which should solve any transcode problems I am facing now.

 

[jgreco]

ZFS doesn't do RAID5 or RAID6, you're basically talking about the wrong things here. ZFS does offer RAIDZ1 and RAIDZ2 which share some superficial similarities to RAID5 and RAID6, but work completely differently. If you want better engagement with the community, I suggest that you might read up; we have excellent resources such as the Terminology and Abbreviations Primer and Introduction to ZFS resources.

 

[beowu!f]

Thank you for that! I started reading the links. I worked at Sun when ZFS was created.. recall using it way back then. Very cool file system.
So.. though I have more to read, I think RAIDZ1 is the way to go for my use.

 

[jgreco]

I am still unclear how Plex server handles transcodes. I thought the playback engine (e.g. Apple 4K Player) did the transcoding in real time (via the plex app). I am unclear how the plex app determines it needs to transcode on the fly. It seems to me transcoding when it is first added to the NAS would save on any real time transcode needs and playback should be smooth. I suspect I may be seeing transcode issues which would mean that even the latest 2021 4K Apple TV can't really play 4K HDR content very well.

I'm ignoring big bits of your messages because I'm a bit busy and I don't really have a lot of time.

Transcoding, in Plex, is the process of having the server (not the client!) change the format of a stream from what is stored on disk to a different one, for one of many reasons, which can include: client compatibility, client bandwidth restrictions (such as remote users), subtitle burning, etc.

In order to transcode, you need one of: a crapton of raw server CPU power, a supported GPU on Linux, or the Intel Quick Sync Video CPU extensions. There are ups and downs to them all.

The Plex client app and the server negotiate capabilities at runtime. In general, for local wired networks, it is best (most performant) to use Direct Play, which means that if your on-disk format is something that the player understands natively, the server merely shovels it across the network verbatim, which is very light load for the server, and generally most responsive to end-user actions like fast forward/etc.

You should opt to use a highly-compatible file format for your media files, one that can be natively handled by any of the clients you use. If you use something that your clients cannot handle directly, you will be forced to transcode. If you like stuff like subtitles, using a subtitle format such as external SRT that is widely supported will generally prevent the server from having to transcode merely to burn the text into the stream. If you have a player with limited stereo sound capabilities, including both a generic stereo stream alongside fancier 7.1 encodings in your library files is a good idea.

So the smartest thing to do is to invest the time up front to encode your video files in a highly compatible format for whatever players you have or expect to use. This represents a one-time investment of CPU to encode up front, rather than a mandatory transcode at runtime, which is a common Plex new user error.

 

[beowu!f]

So the smartest thing to do is to invest the time up front to encode your video files in a highly compatible format for whatever players you have or expect to use. This represents a one-time investment of CPU to encode up front, rather than a mandatory transcode at runtime, which is a common Plex new user error.

Thank you! Totally makes sense. I am FINE with plex server encoding stuff.. HOWEVER.. ideally I would want it in two formats. As I rip blurays to a large format (e.g. h.265 but 10bit HDR, etc).. one player that I know of, the nVidia Shield (currently) can play that format. Actually I guess a PC player could? Not sure. For the REST of players (e.g. phone plex app, plex on TV, etc), I would ideally want.. I think, an h.264 mpeg4 format. As this is a TrueNAS and not Plex forum, I'll look up how to do this.. but basically I want to find a way to have BOTH files stored so that when nVidia Shield is used on my main TV, it uses the big 4K file so it looks/sounds great. For other clients, e.g. phone plex, hopefully I can store a 2nd encoded file so encoding is not done in real time... and can play that smoothly.

 

[jgreco]

Plex does support having multiple versions of media provided to it by you, and it also has an "optimized versions" feature, described here. Apparently there are ins and outs to both strategies, buyer beware.

 

[elorimer]

Since optimized versions can be created and recreated, I wonder if a strategy would be to put the optimized versions in a different dataset, or even a different pool, that is not backed up or even snapshotted. Perhaps in a new striped pool of 2 of those extra nvme drives. Keep the original big files in a pool with redundancy/backups and observing the overall pool usage, but putting the smaller versions in a different pool with none of that.

 

[beowu!f]

I just discovered that. :) Thanks.