Spinning hard drives offer capacity at scale, but they are slow on random I/O and add latency to synchronous writes. SSD caching bridges the gap — a small flash tier accelerates the hot path while leaving bulk storage on HDDs. In ZFS, three distinct cache types serve three different performance problems. This guide explains when (and when not) to use each.
The Three ZFS Cache Types
L2ARC (Read Cache)
A secondary, SSD-backed read cache that extends the ARC. Frequently-read data that falls out of ARC is promoted to L2ARC instead of being re-read from the HDD pool.
Best for: Random read-heavy workloads, large datasets that exceed ARC capacity
SLOG (Write Cache)
A dedicated write log that absorbs synchronous writes at SSD speed. ZFS can acknowledge a write as soon as it lands on the SLOG, then batch-flush it to the main pool asynchronously.
Best for: NFS, databases, VMs, any workload that uses fsync / O_SYNC
Metadata vdev
A special vdev (special allocation class) that stores metadata and optionally small blocks on a fast SSD while bulk data remains on HDDs.
Best for: Directory-heavy workloads, small-file storage, anything with slow directory listings
L2ARC — Read Cache That Can Backfire
L2ARC (Level 2 ARC) is an SSD-backed extension of ZFS's in-memory ARC. When the ARC is full and a new block needs to be cached, ZFS evicts the least-recently-used ARC entry to L2ARC rather than discarding it. A subsequent read for that block hits the SSD instead of the HDD pool — a significant win when your working set exceeds available RAM.
L2ARC consumes ARC for its index
Every block stored in L2ARC requires an entry in ARC's L2ARC header table — roughly 80 bytes per 128 KB block. A 512 GB L2ARC needs about 320 MB of ARC just for the index. On a system with limited RAM, a too-large L2ARC can reduce performance by crowding out frequently-accessed data from ARC. General guidance: do not add L2ARC unless ARC is regularly 80%+ full, and size L2ARC at no more than 5–10× ARC size.
When L2ARC helps: Large datasets accessed repeatedly by many clients (e.g., media libraries, shared document repositories, build caches). The working set exceeds ARC (RAM) but fits on a reasonably-sized SSD.
When L2ARC hurts: Sequential workloads (video streaming, large transfers) — the HDDs can stream as fast as the reader needs, and caching sequential blocks just wastes SSD writes. Also on low-RAM systems where the L2ARC index pressure reduces effective ARC size.
Sizing: Start with no L2ARC. Monitor ARC hit rate with arc_summary or arcstat. If ARC hit rate stays above 90%, you do not need L2ARC. If it drops under 80% and RAM cannot be upgraded, add L2ARC at 2–5× your ARC size. Beyond 10×, the index overhead is likely counterproductive.
SLOG — Small, Fast, Critical for Sync Writes
The SLOG (Separate Intent Log) is not a general-purpose write cache. It does not store data permanently. It serves one purpose: absorb synchronous writes at SSD speed so the application can continue immediately.
When an application issues a synchronous write (e.g., NFS commit, database transaction log) ZFS writes the data to both the main pool and the SLOG. The write is acknowledged as soon as it lands on the SLOG — typically in microseconds on NVMe. Every 5 seconds (the default txg timeout), the accumulated SLOG data is flushed to the main HDD pool and the SLOG is freed.
SLOG sizing guideline
A SLOG only needs to hold the data written in one transaction group. With the default 5-second txg timeout, 5–20 GB is more than enough for any home or small-business NAS. The Intel Optane 905P (if you can find one) is the gold standard for SLOG because of its ultra-low latency and high endurance. Alternatively, any NVMe drive with a power-loss protection (PLP) capacitor, such as a Samsung PM9A3 or Micron 7450 Pro, works well. See our dedicated SLOG guide for recommended models and configuration.
Crucial: Always mirror your SLOG. If the SLOG fails and the txg has not yet flushed, data acknowledged to the client but not yet written to the pool is lost. A mirrored SLOG eliminates that single point of failure. Also, ensure the SLOG device has power-loss protection (PLP) — consumer SSDs without PLP can corrupt the intent log during a power failure, defeating the purpose.
Metadata vdevs — Accelerating Directories and Small Files
ZFS's special allocation class (often called a "metadata vdev" or "special vdev") lets you store metadata — directory entries, file attributes, indirect block pointers — on a fast SSD while bulk data stays on HDDs. You can also configure it to store small blocks (typically under 128 KB) on the SSD as well, which benefits workloads with many tiny files.
The result is dramatically faster ls,find, and directory traversal. A pool of 10 × 20 TB HDDs can take 10+ seconds to list a directory with 10,000 files. With a metadata vdev on NVMe, the same operation completes in under a second.
Metadata vdev sizing guideline
Metadata typically consumes 0.1% – 1% of total pool capacity. For a 100 TB pool, plan for 100 GB – 1 TB of metadata space. If you also store small blocks on the special vdev, the size depends on the number of small files — estimate generously (2–5% of pool size). Mirror the special vdev — losing it means losing the entire pool, even if the data disks are intact.
Synology hybrid equivalent: Synology's SSD cache in "metadata mode" performs a similar function by pinning metadata on the SSD. However, Synology's implementation caches metadata reactively rather than dedicating space for it, and it cannot offload small-block writes. ZFS's special vdev is a dedicated allocation target, giving more predictable performance.
NVMe vs SATA for Cache Devices
For SLOG: Latency is everything. NVMe drives deliver sub-10 µs write latency compared to SATA's 50–100 µs. A SATA SSD used as SLOG can saturate at 80–150 MB/s; NVMe handles 1 GB/s+ with the same latency profile. Always choose NVMe with PLP for SLOG.
For L2ARC: Bandwidth matters more than latency. SATA SSDs can deliver 500–560 MB/s sequential reads — enough for most home NAS scenarios. NVMe drives offer 3–7 GB/s, which helps when multiple clients are all landing L2ARC cache misses simultaneously. However, PCIe lane availability is often the constraint — a single NVMe drive uses 4 PCIe lanes.
For metadata vdevs: NVMe is strongly recommended. Metadata access is latency-sensitive and often random — NVMe's parallel queue architecture handles concurrent deep directory walks far better than SATA's single-queue AHCI protocol.
Practical advice: use whatever M.2 or U.2 slots your motherboard provides. A single NVMe drive partitioned for SLOG (20 GB) + metadata vdev (100–500 GB) + L2ARC (remaining) is a common and practical approach on systems with limited PCIe slots. See our performance methodology guide for benchmark comparisons.
Synology SSD Cache vs ZFS Cache
Synology DSM offers two SSD cache modes: read-only (similar to L2ARC) and read-write (similar to SLOG + L2ARC combined). The Synology implementation operates at the block layer of Btrfs/RAID, not at the filesystem layer like ZFS.
Synology advantages
Simpler setup — one checkbox in DSM
Read-write cache provides crash safety
Transparent to the filesystem
Works with non-ZFS pools (Btrfs, ext4)
ZFS advantages
Fine-grained control — L2ARC, SLOG, metadata vdevs are independent
Metadata vdevs are a dedicated allocation target, not a cache
ARC + L2ARC with adaptive replacement eviction
Checksummed cache data — no silent corruption in cache reads
For most home users, Synology's SSD cache is perfectly adequate. For power users, TrueNAS SCALE or Proxmox with ZFS offers far more fine-grained control and the flexibility of dedicated metadata vdevs.
L2ARC vs SLOG vs Metadata vdev — Quick Reference
Property
L2ARC
SLOG
Metadata vdev
Type
Read cache (level 2)
Write log / intent log
Dedicated allocation target
Data persisted?
Volatile — lost on reboot, rebuilt from access patterns
Persistent but temporary — flushed each txg (~5 s)
Persistent — metadata lives here permanently
Impact of device loss
Minor — L2ARC just disappears, ARC hit rate drops
Critical — unflushed sync writes are lost
Critical — whole pool becomes unavailable
Recommended size
2–10× ARC size; min 64 GB
5–20 GB (mirrored)
0.1–1% of pool for metadata only; 2–5% with small blocks
RAM cost
~80 bytes per 128 KB block (index in ARC)
Minimal — log entries tracked in ZIL
Minimal — metadata is data, no dedicated index
Best drive type
NVMe or SATA SSD (bandwidth-driven)
NVMe with PLP (latency-driven)
NVMe (latency + random I/O driven)
Must be mirrored?
No (cache loss is non-fatal)
Yes (data loss risk)
Yes (pool unavailable on loss)
Works with HDD pool?
Yes
Yes
Yes (also works with all-flash pools for tiering)
Frequently Asked Questions
Can I add L2ARC or SLOG to an existing pool?
Yes. Both L2ARC and SLOG are attachable to an existing pool with zpool add — no need to destroy the pool or offline any drives. Metadata vdevs can also be added to an existing pool, but only new metadata writes go to the SSD; existing metadata stays on the HDD pool. For best results, add a metadata vdev immediately after pool creation. Use our ZFS RAID calculator to plan your full pool layout including cache devices.
Does L2ARC help with Plex / Jellyfin media streaming?
Rarely. Media streaming is sequential — a single 4K Blu-ray remux reads a long contiguous stream of data at 50–150 MB/s. HDDs handle sequential reads at 200–280 MB/s easily. L2ARC would cache the first 128 KB of every file and waste SSD endurance on data that is only read once. If your media library has many concurrent users, a larger ARC (more RAM) helps with repeated directory listings and metadata, but L2ARC is generally not worth it for media servers.
Should I use a single SSD partitioned for both SLOG and L2ARC?
Yes — this is a common practice on systems with limited PCIe/M.2 slots. Partition the first ~20 GB as SLOG (mirrored if you have a second SSD) and the remainder as L2ARC. Note that SLOG benefits from PLP, so choose an SSD with power-loss protection if possible. Consumer NVMe drives like the Samsung 970/990 Pro can work for L2ARC but lack PLP for SLOG — use a dedicated PLP-equipped drive for SLOG if data integrity is critical.
How do I monitor ZFS cache performance?
Use arcstat (from the zfs-monitoring package) to watch ARC hit rate in real time. Thezpool iostat -l 1 command shows per-disk latency — if the HDD pool shows sustained high latency and ARC hit rate is below 80%, L2ARC may help. For SLOG, monitor zilstat or check the SLOG device write rate with iostat -x 1 | grep sdX to ensure the SLOG is absorbing sync writes. Our performance methodology guide covers monitoring in depth.
Plan your ZFS pool with cache devices
Our interactive ZFS RAID calculator now includes cache device support — add SLOG and L2ARC to your pool configuration and see the full layout, fault tolerance, and usable capacity before you buy hardware.