ZFS Caching Explained: ARC, L2ARC, and SLOG

Updated on Sep 23, 2026

11 min read

ZFS caching is often described as “add an SSD and make the pool faster,” but that shortcut hides three different mechanisms. ARC is the main memory cache, L2ARC is an optional secondary read cache, and SLOG is a separate device for the intent log used by synchronous writes. They solve different problems, have different failure and capacity implications, and should be selected from workload measurements rather than from capacity alone. This guide explains ZFS caching for NAS builders, home-lab operators, and administrators running virtual machines or databases on OpenZFS.

What Is ZFS Caching?

OpenZFS is both a filesystem and a volume manager. Its storage stack uses checksums, copy-on-write updates, pooled storage, and configurable caching to balance integrity and performance. The OpenZFS documentation describes the platform’s core concepts and device types, while its performance and tuning documentation covers the cache paths in more detail.

The word “cache” is imprecise in this context. ARC and L2ARC cache data that may be read again. A SLOG does not generally make ordinary asynchronous writes faster; it records synchronous write intent on a fast, durable device so the system can acknowledge those writes without waiting for the main pool to complete them. A SLOG is therefore a device for the ZFS Intent Log (ZIL), not a write-back cache for every application.

At a high level, a read may be served from:

ARC, which is the primary in-memory Adaptive Replacement Cache.
L2ARC, an optional extension of read caching on SSD or NVMe.
The main pool, such as an HDD mirror or RAID-Z vdev.

Synchronous writes take a different path. ZFS records their intent in the ZIL; if a separate log device is configured, that log is placed on the SLOG. The committed data still belongs to the main pool. A failed SLOG should not make a correctly configured pool lose committed data, but it can remove the low-latency log path and may require recovery of outstanding transactions.

Why ZFS Has These Mechanisms

Storage media have different latency, capacity, and cost characteristics. DRAM is fast but limited and volatile. SSDs are slower than memory but much faster than many disks. HDDs are inexpensive for capacity but have high seek latency. A single pool may serve large media files, repeated metadata reads, virtual machine disks, and database transactions at the same time.

ZFS already uses system memory intelligently, so an administrator does not need to add a cache device for every workload. ARC keeps recently and frequently useful blocks in RAM, and its adaptive policy tries to balance recently used data with frequently used data. If the working set fits in available memory, adding L2ARC may provide no benefit. If the workload is dominated by sequential reads, the cache may also be bypassed or have little opportunity to help.

The practical question is not “which cache is fastest?” It is “which part of this workload is waiting, and can the proposed device improve that path without consuming resources needed elsewhere?”

How ARC, L2ARC, and SLOG Work

ARC: the primary read cache

ARC lives in host memory and is the first place ZFS looks for cached data. It can contain both file data and metadata, such as block pointers and directory information. Metadata-heavy workloads, including many small files and virtual machine images, may benefit even when the total file data is too large to fit in RAM.

ARC is volatile. Data in ARC is not the only copy of a committed block, and a reboot normally empties the cache. More RAM can improve hit rates, but allocating nearly all memory to ARC can starve the operating system, containers, virtual machines, or applications. The right ARC size is a workload and platform decision, not a universal ratio of RAM to pool capacity.

L2ARC: an optional secondary read cache

L2ARC uses one or more cache devices to extend the read cache beyond ARC. It stores copies of blocks that originated on the main pool; it does not replace the pool’s authoritative data. If an L2ARC device is lost, the pool should remain usable, although cached reads will fall back to the main vdevs.

L2ARC has costs. It consumes device bandwidth, may require memory for cache metadata, and has to be populated from reads over time. A cold or constantly changing workload may never reuse enough data to repay those costs. L2ARC is most plausible when the active read set is larger than RAM, reads are repeated, the primary pool is much slower than the cache device, and measurements show that ARC misses are expensive.

SLOG: a separate ZIL log device

The ZIL protects the ordering and durability semantics of synchronous writes. Applications can request synchronous behavior with operations such as fsync, fdatasync, or database commits. ZFS must preserve the promise that a successful synchronous write survives a crash, subject to the pool and hardware’s durability guarantees.

A separate log device, or SLOG, gives those log records a low-latency location. It is especially relevant to workloads with many synchronous writes on a pool made of slower disks, such as NFS datastores, virtual machine storage, and some databases. It is not normally useful for a media library dominated by large asynchronous writes.

SLOG devices should have power-loss protection, low latency, adequate endurance, and a layout that matches the required fault tolerance. A single consumer SSD can become a new failure point even if the main pool is redundant. Mirrored log devices are appropriate when the workload and platform require continued log-device redundancy. Check the current platform documentation before selecting a topology.

Comparing the Three Mechanisms

Feature	ARC	L2ARC	SLOG
Primary purpose	Cache reads in memory	Extend read caching onto fast storage	Accelerate and protect synchronous intent logging
Data type	Cached data and metadata	Copies of pool blocks	Log records for synchronous transactions
Persistence after reboot	No, normally repopulates	May persist some cache metadata/data depending on implementation, but is not authoritative	Outstanding log records are replayed when needed
Main resource	DRAM	SSD/NVMe capacity, I/O, and metadata memory	Low-latency, power-loss-protected storage
Helps sequential media reads?	Sometimes	Usually little	No
Helps synchronous database/NFS writes?	Not directly	No	Often, if the pool is the bottleneck
Failure impact	Cache is lost; pool data remains	Cache is lost; reads fall back to the pool	Reduces log performance or changes recovery path; design for redundancy
First tuning action	Measure memory pressure and hit rate	Prove repeated reads and an ARC miss bottleneck	Verify sync-write latency and device durability

Key Design Decisions

Match the cache to the I/O pattern

Workload shape matters more than the label “NAS.” A photo archive with large sequential reads may be limited by network bandwidth, not disk latency. A VM datastore creates small random reads and synchronous writes, making latency and IOPS more important. A backup target may write large streams once and rarely read them again, which is a poor L2ARC candidate.

Dataset properties also matter. Compression can reduce physical I/O and make cached data more effective, while a suitable recordsize can reduce read amplification for known workloads. These properties should be set at dataset boundaries and tested with representative data; changing them is not a substitute for measuring the application.

Preserve memory for the whole system

ARC competes indirectly with applications for RAM. A TrueNAS host running apps or virtual machines is not only a storage appliance. Reserve enough memory for the operating system and guests, and watch for swapping or memory pressure before increasing cache targets. A larger cache that makes the database unstable is a net performance loss.

Treat cache devices as hardware with an operational lifecycle

Consumer SSD endurance, firmware behavior, thermal throttling, and power-loss characteristics vary. An SSD that is adequate for a read cache may be inappropriate for a SLOG because synchronous durability depends on the device honoring flush and stable-write semantics. Review vendor specifications and test behavior under power-failure conditions where the workload justifies it.

Real-World Use Cases

Home media and file storage

Start with ARC and a healthy main pool. Large media files are commonly read sequentially, and clients may be limited by a one- or two-and-a-half-gigabit network. L2ARC rarely fixes a network bottleneck. A SLOG is generally unnecessary unless clients or applications are issuing meaningful synchronous writes.

Virtual machine and container storage

VMs can generate random reads, metadata activity, and synchronous writes. First choose an appropriate vdev layout and ensure the pool has enough IOPS. Then measure latency during the actual workload. L2ARC can help with a stable, repeatedly accessed working set larger than RAM; SLOG can help only with the synchronous portion and only when the log device is faster and durable.

NFS and database workloads

NFS clients and databases may rely on synchronous semantics. A separate SLOG can reduce commit latency when the main pool is slow, but it cannot compensate for insufficient CPU, network, vdev IOPS, or a poorly sized database. Validate durability and recovery behavior rather than optimizing only a benchmark that ignores flushes.

Getting Started and Measuring Safely

Before adding a device, capture a baseline during normal and peak workload periods. The following commands are read-only observation tools on a Linux OpenZFS host:

# Pool health and configured devices
zpool status -v
zpool list
zpool get all tank | grep -E 'cachefile|listsnapshots'

# Per-vdev throughput and latency samples
zpool iostat -v tank 5

# Dataset properties relevant to I/O
zfs get compression,recordsize,sync tank/data

On Linux, ARC counters are commonly exposed through the ZFS statistics interface:

grep -E '^(hits|misses|size|c|c_max) ' /proc/spl/kstat/zfs/arcstats

The exact statistics interface differs across operating systems and OpenZFS packaging. Compare hit and miss behavior over a representative period, not a single command output. Also record application latency, CPU use, memory pressure, network throughput, and pool utilization. A cache hit-rate increase is not automatically a user-visible improvement.

If a test shows that L2ARC is justified, add a purpose-selected cache device using the platform’s documented management path. For a command-line example on a test pool, the general operation is:

# Inspect the pool first; replace the device path only after identifying it safely.
sudo zpool add tank cache /dev/nvme1n1

# Verify the cache device is attached.
zpool status tank

Do not run a pool-modifying command against an unverified device. L2ARC is not a backup and should not be used to hold the only copy of any data. Similarly, add a SLOG only after verifying synchronous write latency, device power-loss protection, endurance, and the desired failure topology:

# Example only: use a stable device identifier and the platform's documented syntax.
sudo zpool add tank log /dev/disk/by-id/<power-loss-protected-log-device>
zpool status tank

After a change, repeat the same workload and compare end-to-end latency. Keep a rollback plan, document the device serial number, and monitor temperatures, wear, errors, and pool alerts. A cache should be removed or replaced through the ZFS management procedure, never by simply unplugging it or deleting its partition.

Common Misconceptions

“L2ARC turns an HDD pool into an SSD pool.”

It only helps reads that are reused and successfully retained. First reads still come from the main pool, writes still land according to the pool’s normal behavior, and sequential or cold data may not benefit. Network, CPU, vdev layout, and application behavior can remain the real bottleneck.

“SLOG is a write cache for the whole pool.”

SLOG primarily serves synchronous intent logging. It does not make every asynchronous write faster, and it does not permanently store user data independently of the main pool. Its value comes from reducing the latency of durable synchronous commits.

“Any SSD is safe for SLOG.”

A SLOG depends on correct durable-write behavior during power loss. Consumer endurance and volatile write caches can make an otherwise fast SSD a poor choice. Use hardware with appropriate power-loss protection and validate the complete storage path.

“More cache always means more performance.”

Extra cache can consume RAM, add device writes, increase heat, and complicate failure handling. Measure before and after, and remove a cache that does not improve the target workload.

For the surrounding storage decisions, see:

ZFS caching works best as a measured extension of a sound pool design. Give ARC enough memory without starving applications, add L2ARC only for a proven repeated-read workload, and reserve SLOG for synchronous-write latency backed by durable hardware. Pool topology, backups, monitoring, and recovery testing remain more important than any single cache device.