TrueNAS read-cache sizing guide
TrueNAS L2ARC Sizing: RAM, Cache SSD & Workload
L2ARC is a second-level read cache on SSD. It can help when a frequently reused working set is larger than ARC in RAM and the underlying pool is much slower at random reads. It does nothing for writes, and an oversized cache can consume enough ARC metadata to make a poorly designed system worse.
Quick answer
Add RAM first, then add L2ARC for a measured read problem
TrueNAS recommends treating RAM as the faster first-level cache. L2ARC is most useful for repeated random reads where the active working set exceeds RAM. Current TrueNAS guidance gives roughly 5× to 20× RAM as a broad L2ARC capacity range, but the real requirement should be bounded by the reusable working set and RAM metadata cost.
Live Amazon hardware
Current hardware for this TrueNAS decision
Products come from this sprint's dedicated catalogue. SSD, ECC memory, NIC, DAC and optical classes stay separate. Ambiguous capacities, external drives, USB NICs, enclosures, complete computers, multipacks and incompatible memory types are rejected.
Buying decision
Do not buy a 4TB cache SSD because 4TB sounds better
A cache larger than the reusable hot data wastes capacity, takes longer to warm and consumes ARC metadata. Start from ARC misses and the active data set. If the pool is already fast all-flash storage or the workload is mostly one-pass sequential reads, another SSD may deliver little benefit.
Interactive decision tool
TrueNAS L2ARC Sizing Calculator
Use the inputs to narrow the hardware role before shopping. Results are planning guidance. Verify current TrueNAS/OpenZFS behavior, motherboard support, exact SSD specifications, ECC compatibility and backups before deployment.
Compatibility checklist
Four checks before buying TrueNAS acceleration hardware
ARC, L2ARC, SLOG and special are different
RAM is the primary read cache; L2ARC is secondary read cache; SLOG serves synchronous writes; special vdev stores real allocations.
Compatibility comes before price
Verify ECC type, SSD interface/form factor, PCIe lanes, NIC media and motherboard support for the exact part.
Do not infer enterprise features
PLP, TBW/DWPD, ECC mode and module buffering are shown only when the listing or exact specification supports them.
Backups remain separate
ECC, mirrors, cache devices and auxiliary vdevs solve specific failures. They do not replace independent local and offsite backups.
ARC is the cache to understand before L2ARC
ARC lives in system RAM and serves hot ZFS data with much lower latency than an SSD. OpenZFS adapts between recently used and frequently used blocks, which is why adding adequate RAM is usually the first cache upgrade.
L2ARC extends that read cache onto flash after data is considered for eviction from ARC. It is not a replacement for RAM and it cannot make a starved system behave as if SSD capacity were memory.
L2ARC only helps reads
Cache devices hold another copy of blocks that remain on the main pool. Writes still go to normal vdevs through ZFS write semantics; a SLOG is the separate mechanism relevant to synchronous write latency.
If the complaint is slow backups or slow writes, L2ARC is usually the wrong hardware purchase. Identify whether read IOPS and repeated access are the limiting path.
Random repeated reads are the strongest workload
Virtual-machine images, frequently accessed project data, metadata-heavy shares and other working sets repeatedly revisited can benefit when they exceed ARC but fit partly in flash cache.
Large sequential scans that are read once can displace useful cache content and may not benefit. OpenZFS has tuning around prefetch and cache behavior, but hardware should be justified before tuning begins.
TrueNAS offers a 5x to 20x RAM guideline
The TrueNAS hardware guide gives a broad L2ARC capacity guideline of roughly five to twenty times installed RAM. That is a starting range, not a requirement to fill. A 64GB system therefore does not automatically need 1.28TB of cache.
Cap the result by the reusable working set. If only 200GB of data is repeatedly hot outside ARC, a multi-terabyte L2ARC will not magically create more useful cache hits.
L2ARC consumes ARC metadata
Every cached block needs metadata in main memory. TrueNAS illustrates the cost dramatically: a 480GB cache filled with 4KiB blocks can require more than 10GiB of metadata in ARC.
Block size matters. The calculator therefore gives a conservative metadata warning instead of subtracting one fixed percentage for every workload.
Persistent L2ARC changes warm-up behavior, not the basic sizing logic
Modern OpenZFS can persist L2ARC metadata across reboots and rebuild the cache view asynchronously when a pool is imported. This reduces the need to start completely cold after every restart.
Persistence does not turn L2ARC into permanent storage. The data still exists on the pool and losing the cache device remains a performance event rather than a pool-integrity event.
Cache devices are striped, not mirrored
OpenZFS cache vdevs do not need mirror redundancy because their contents are duplicate copies. Multiple cache devices contribute independent cache capacity rather than a redundant data mirror.
If a cache SSD fails, ZFS can read the block from normal pool storage. This is fundamentally different from the redundancy requirement of a special vdev.
The L2ARC SSD must beat the pool at the relevant I/O
TrueNAS emphasizes random read performance because the device should service cache hits faster than the storage it fronts. One ordinary SSD in front of a large all-flash pool can be slower than simply reading from the pool.
HDD pools are the clearer target. NVMe often provides excellent random-read capability, but a SATA SSD can still be useful when it provides far more IOPS than the disk array and the platform lacks spare NVMe lanes.
Endurance matters because cache devices are written continuously
L2ARC is a read cache from the client perspective, but ZFS must write cache content onto the SSD as ARC entries are evicted. That can create sustained background writes over a long service life.
Choose an SSD with reasonable endurance and cooling for the intended fill rate. Do not judge a cache candidate only by read benchmark numbers.
A large ARC can make L2ARC unnecessary
If the active working set fits comfortably in RAM and the ARC hit rate is already high, L2ARC may sit underused. More flash does not improve a workload that is already served from memory.
For small home NAS systems, upgrading from 16GB to 32GB or 64GB can be simpler and more broadly beneficial than adding a dedicated cache device.
Network speed can hide or expose cache value
A 1GbE client cannot consume storage faster than the network ceiling, so an HDD pool may already saturate the link for sequential transfers. L2ARC will not make that file copy exceed the network.
At 10GbE, random read limitations can become more visible, but cache only helps if the requested data is actually in L2ARC. Match storage tuning to the access pattern, not the NIC label.
Measure hit rate after deployment and remove bad cache designs
After adding L2ARC, monitor cache occupancy, hit rate, ARC pressure and SSD health. A low hit rate can reveal that the workload does not reuse enough data or that the cache is badly sized.
Because cache vdevs are auxiliary, they can be removed without losing pool data. That makes L2ARC a safer experiment than a special vdev, but it is still better to calculate before buying hardware.
Questions people ask
TrueNAS L2ARC questions
What is the difference between ARC and L2ARC?
ARC is the primary ZFS cache in RAM. L2ARC is an optional second-level read cache on storage devices such as SSDs.
How large should L2ARC be?
TrueNAS gives a broad 5× to 20× RAM guideline, but the useful size is also bounded by the repeated working set and RAM metadata overhead.
Does L2ARC speed up writes?
No. It is a read cache. SLOG relates to synchronous-write latency, while normal writes go to the pool.
Should I add RAM or L2ARC first?
Usually RAM first because ARC is faster and L2ARC consumes some RAM metadata. Add L2ARC after confirming a read-cache problem.
Does L2ARC need mirroring?
No. Cache data is a second copy of data already in the pool. OpenZFS cache vdevs are not mirrored or RAIDZ groups.
Can L2ARC survive a reboot?
Modern OpenZFS supports persistent L2ARC metadata and can rebuild the cache view after import, although the device remains an auxiliary cache.
Is 4TB L2ARC too large?
It can be if the hot working set is smaller or system RAM is insufficient for cache metadata. Size it from data reuse rather than maximum SSD capacity.
Can consumer NVMe be used for L2ARC?
Yes in many systems if endurance, thermals and random-read performance are suitable. L2ARC does not hold the only copy of data.
Does L2ARC help a pool of SSDs?
Sometimes, but a large all-flash pool can already provide more IOPS than one cache device. Measure before adding another layer.
Can I remove L2ARC later?
Yes. Cache devices are auxiliary and their loss/removal does not remove the original pool data.
Official references and methodology
Verify the exact TrueNAS, OpenZFS and hardware behavior
L2ARC sizing follows current TrueNAS and OpenZFS cache behavior, including the RAM metadata cost and the distinction between ARC, cache vdevs and write-path devices. Live SSDs are shown as cache candidates, not guaranteed performance upgrades.
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, model revisions, memory compatibility, endurance, PLP, firmware and marketplace conditions can change. Verify the exact part before purchase.