I suppose this was all planned, however I didn’t really expect it to come up so quickly. Such is life when you come across some sweet deals though! I ended up adding a 16GB kit of DDR4 bringing my RAM to 32GB which should give me some room for more VMs/containers when it comes up, but more importantly, more room for 4K transcode cache. It’s still undecided if this makes a big difference, but updating the MediaStack container to 16GB of available memory lets me map about half of that to a transcode directory. All in the RAM came to under $50 shipped.
22TB for less than $400? I regret not getting two!
The other upgrade added was 22TB of spinning disk storage courtesy of Western Digital. I grabbed one of the 22TB Western Digital My Books for a ridiculously cheap $360 shipped due to a coupon stacking error. After verifying the drive was functional I shucked it and ended up with a 22TB white label enterprise class 7200RPM helium-filled drive. It found it’s way very quickly into the server and after a bit of fiddling around was mounted and accessible. My only issue was how do I present two drives to Plex at the same time in a seamless way? Mapping libraries in different drives is a pain, and the wait time for a fresh file being copied from the SSD to the HDD isn’t a solid user experience. On top of that copies could introduce I/O overhead, possibly leading to stuttering, again, another user experience no-go. I decided to go with MergerFS.
MergerFS is a union file system that can present multiple mounts as a single mount point to software. It handles writing data to different drives in different methods. In my case, I’ve got it setup to present both the SSD and the HDD as a single mount point, and MergerFS writes all data to it’s “first found” drive. With my configuration First Found is the SSD. I setup a cron job that runs daily at 5AM to move files older than 14 days off the SSD and onto the HDD, then cleans up empty directories. This should accomplish a few things:
New content is downloaded and served off fast storage.
Content being downloaded while content is being streamed should have minimal impact to the streaming experience due to the high IOPS of an SSD.
Older content is moved automatically during low/no use times to ensure no user experience impact.
The SSD is regularly cleaned keeping storage usage there to a minimum, allowing me to use it for other things like serving up my Lightroom back catalog over the network.
A single disk loss doesn’t mean all data on the other disks is lost. This is better than a JBOD but not as good as RAID, which is perfectly fine for a media server.
So far this has been working great. Initial copy of back catalog content saw an average write speed just over 200mb/s, which is awesome for a spinning disk. Content streamed from the spinning disk is served relatively quick with no noticeable user impact. The move script has been executing daily without issue as well. Looking forward to seeing how long it takes to chew through this much space!