I was wondering if anyone is running L2ARC for a plex storage pool. I don’t need all the links to how ZFS and L2ARC work…I have read them all. I’m just curious if anyone is currently running L2ARC with plex and what size are they using? I have a raidz3 with 12 24tb drives and 128gb of ddr5 ecc ram. I was wondering what the real world results would be running either a 1tb nvme or a 4tb nvme as the L2ARC before I make a purchase. I’m mostly looking for quicker reads with large files ranging from 4-10gb. As always thank you for all the input. Truenas has an absolutely awesome community!
ARC and L2ARC kick in when you read the same data over and over again.
Are you planning on watching the same videos multiple times in a amount short time?
If not, what’s more likely to be beneficial is to simply store the metadata, speeding up directory listing and the like.
You can make due with a much smaller L2ARC set to metadata only. If you end up not being happy with the result the L2ARC is removable.
I advice against adding a Special vdev. That is pool critical and can’t be removed if you change your mind. L2ARC is much more flexible.
Well mostly kids shows and series that we regularly watch. I have read about the Special vdev for metadata but I wish it kept that data on both (metadata vdev and the original pool) so it wouldn’t destroy the whole pool. Even with a triple mirror it still makes me leery. Besides metadata only what are the other setting options for it?
Do you hold your Plex metadata on SSD (as opposed to ZFS metadata)?
So I have the main storage pool which is all 24tb drives which all the plex media resides on. I also have three nvme 4tb Seagate 530s in raidz1 for all the apps which is where plex resides on.
Well that wasn’t a direct answer but I guess I can assume that with 8TB of useable SSD storage you are not simply storing the Plex docker image on there but are also using it to store the Plex metadata.
Yes sorry about that. All the metadata is on that nvme pool. Would L2ARC work for the metadata portion or depends on how often its used?
I am unclear whether you want L2ARC for your HDD or SSD pools - but it needs to be for one or the other.
However, IMO it is unlikely that L2ARC will actually give you any noticeable benefit…
-
The L2ARC vDev has to be significantly faster technology than the data vDev for it to have any chance of helping. So L2ARC for the NVME pool won’t do anything.
-
ZFS does sequential pre-fetch on the media files on HDD - so either your HDDs are not fast enough to load the data Plex needs to stream (in which case your Plex client will be pausing to buffer every few seconds making it unwatchable) or ZFS will have pre-fetched the next block of media file for when the client requests it. So L2ARC for your media HDD pool (if we assume that your media file is actually in L2ARC - and it probably won’t be) would only make a difference on the very first read of file metadata and then data from disk - i.e. it might save 1/10sec on the time it takes for the stream to start being shown.
So personally, I doubt that it would make any noticeable difference - and if you have a noticeable performance issue, then there are probably other solutions you need to be looking at.
Run arc_summary
in the shell and post the output here as formatted text (</>
button).
The system must have been up and actively used for some time for the results to be meaningful.
Expectations: Unless you stream the very same movies ever and ever, you cannot expect faster reads. Caching directory metadata could speed up browsing through the collection, but with 128 GB RAM everything may be in ARC already.
Expectations: EVEN IF you stream the very same movies over and over, you won’t even notice the faster reads from L2ARC on your media pool when watching the TV programme. With your Plex metadata on NVMe already, browsing shows in the Plex client will already be as fast as it can be from a data reading perspective and L2ARC won’t speed it up - if you want faster Plex browsing for shows, then you will probably need to pre-load ARC using a script or faster networking.