ZFS cache and log decision guide
Proxmox ZFS SLOG vs L2ARC: What They Do and What to Buy
SLOG and L2ARC are both optional ZFS devices, but they solve completely different problems. SLOG is a separate log vdev used for the ZFS intent log path during synchronous writes; it is not a general write-back cache. L2ARC is a second-level read cache containing another copy of data that already exists in the pool. Buying an SSD without identifying which bottleneck exists is the fastest way to add cost without improving Proxmox.
Quick answer
Do you need SLOG, L2ARC, more RAM or none of them?
Start with RAM and workload measurement. Add SLOG only when synchronous-write latency is an actual bottleneck and choose a low-latency, high-endurance device with verified power-failure behavior appropriate to the workload. Add L2ARC when the active read working set is larger than ARC and repeated reads can benefit from a second cache tier. If neither pattern exists, spend the money on RAM, faster primary storage or backups instead.
Live Amazon hardware
Current controllers, cables and storage devices for this decision
These listings come from Sprint 4B's dedicated catalogue. HBA generations, connector families, breakout cables, cooling hardware and enterprise SSD candidates are separated. A marketplace phrase such as “IT mode” is treated as listing evidence, not proof of firmware state.
Buying decision
SLOG accelerates synchronous commit latency; L2ARC caches reads
These roles should never be described as “ZFS cache SSDs” without qualification. A SLOG device participates in the synchronous-write intent-log path, while L2ARC stores extra copies of read data. Their failure consequences, sizing and useful device characteristics are different.
Interactive decision tool
SLOG vs L2ARC Advisor
Use this planner to screen controller class, ports, PCIe bandwidth, passthrough ownership, ZFS cache/allocation-device roles or expansion headroom before buying hardware. Results are planning guidance, not a substitute for motherboard lane/IOMMU documentation, exact HBA firmware verification, current OpenZFS behavior or independent backups.
Compatibility checklist
Four checks before adding an HBA or expanding storage
Decide who owns the disks
Proxmox-owned ZFS and a TrueNAS VM passed an entire HBA are different architectures. Do not let both layers manage the same disks.
Match ports and connectors
Count final drive lanes and verify SFF-8087, SFF-8643, backplane and breakout-cable direction before ordering.
Check PCIe lanes and IOMMU
A full-length slot may run electrically at fewer lanes. Passthrough also depends on platform IOMMU support and usable isolation.
Plan cooling and recovery
HBAs need airflow, and more attached disks increase the data you must protect with an independent backup and documented replacement map.
SLOG is not a write cache for all writes
ZFS uses the intent log for synchronous write semantics. A separate log device can reduce the latency of those commits by placing the log on a fast device, but ordinary asynchronous writes still flow through the normal transaction-group path.
If your workload is mostly asynchronous file copies or media reads, adding SLOG may change almost nothing. Measure sync-write latency before buying hardware.
Power-loss behavior matters for a log device
The value of synchronous writes is durability across crashes and power loss. A device used for SLOG should therefore be selected for predictable latency, endurance and appropriate power-failure behavior, not merely high sequential throughput.
Consumer NVMe may benchmark impressively while providing little evidence about the behavior that matters most for a log device. This catalogue surfaces PLP only when evidence is available and otherwise marks it unverified.
SLOG capacity is usually smaller than people expect
The log device does not need to hold the whole pool or hours of writes. It holds recent synchronous intent until transaction groups commit to normal storage.
That is why latency and durability often matter more than multi-terabyte capacity. Oversizing a log device does not compensate for selecting the wrong device characteristics.
L2ARC is a read cache and losing it is harmless to pool data
OpenZFS treats cache vdevs as second copies of data already stored in the pool. If an L2ARC device fails, the pool still owns the authoritative blocks elsewhere.
This makes L2ARC failure consequences very different from a special vdev. You can be more aggressive about cache-device economics because losing the cache should reduce performance, not lose the pool.
RAM usually comes before L2ARC
ARC in system memory is the primary ZFS cache. RAM has far lower latency than an SSD and also supports the rest of the ZFS metadata structures.
If the host is memory-starved, adding L2ARC can be the wrong first upgrade. Give the Proxmox/ZFS host enough RAM for its workloads before using flash to extend the read cache.
L2ARC helps only when reads repeat
A large sequential scan that is not repeated may not benefit from caching. L2ARC is more useful when the working set exceeds ARC but contains frequently reused blocks.
VM boot images, frequently accessed datasets and repeated read-heavy workloads can fit this pattern. Cold archive data that is read once a month usually does not.
SLOG and L2ARC can coexist because they solve different bottlenecks
A server can legitimately use both a log device and a cache device when it has synchronous-write latency problems and a read working set larger than ARC.
Do not combine the decision into “buy two NVMe drives.” Evaluate each role independently, including failure behavior, endurance and whether the workload actually exercises it.
Virtualization can make sync behavior workload-specific
Databases, NFS exports, guest filesystems and applications can request synchronous semantics differently. A Proxmox host running many guests may therefore have one VM that benefits from SLOG while most others do not.
Use workload tracing and application behavior rather than guest count alone. Ten idle VMs do not create a SLOG requirement.
Fast primary storage can make auxiliary devices unnecessary
An all-NVMe pool already has low latency. Adding a separate SLOG may not move the needle unless the dedicated device is materially better for sync writes. Likewise, L2ARC may be redundant if the working set already fits in RAM.
Auxiliary vdevs make the most sense when they correct a specific asymmetry in the primary pool, such as HDD latency.
A UPS is not a substitute for device semantics
A UPS reduces the chance of abrupt power loss but does not eliminate crashes, firmware faults, cable failures or someone pulling the wrong plug.
Select storage devices according to the semantics you need even when the server has battery backup. Reliability should have multiple layers rather than one assumed protection.
Monitor hit rates and latency after adding hardware
A cache or log device should produce measurable improvement in the workload metric that justified it. Track latency, ARC/L2ARC behavior and application response rather than keeping the device because it was expensive.
If the workload changes, the best allocation of that NVMe slot may change too. L2ARC can be removed more safely than a special vdev because it is only a cache.
Choose the simpler pool when evidence is weak
The default ZFS pool already has sophisticated caching and transaction behavior. Auxiliary devices are optional optimizations, not mandatory components of a serious server.
When you cannot name the bottleneck, do not add the device. More RAM, better primary media or another backup copy usually produces a clearer benefit than speculative tuning hardware.
Questions people ask
Proxmox ZFS SLOG and L2ARC questions
Is SLOG a ZFS write cache?
No. It is a separate log vdev for the ZFS intent log path used by synchronous writes.
Does SLOG speed up asynchronous writes?
Not in the way a general write-back cache would. Its main purpose is synchronous-write commit behavior.
What is L2ARC?
A second-level read cache containing copies of data that already exists in the pool.
Will losing L2ARC lose my pool?
No. L2ARC is a cache, so the authoritative data remains in the pool.
Should I buy more RAM before L2ARC?
Usually yes when the host is short on memory. ARC in RAM is the primary ZFS cache and has much lower latency.
Does a SLOG need power-loss protection?
Power-failure behavior is highly relevant to synchronous durability. Verify the exact device specification rather than assuming every enterprise-looking SSD has the required protection.
How large should a SLOG be?
Usually much smaller than the data pool because it holds recent synchronous intent, not the whole dataset. Workload burst behavior matters more than raw pool size.
Can I use consumer NVMe for L2ARC?
It can be used as read cache, but endurance and write amplification from cache population still matter. The failure consequence is lower than for a special vdev.
Do all Proxmox VMs benefit from SLOG?
No. Benefit depends on synchronous-write behavior and the latency of the primary pool.
Can one SSD be both SLOG and L2ARC?
It is possible to partition devices in complex ways, but combining workloads and failure dependencies makes analysis harder. Dedicated roles are easier to reason about.
Official references and methodology
Verify controller, passthrough and OpenZFS behavior before deployment
The page follows OpenZFS definitions that separate log, cache and special vdev roles. Hardware recommendations are role-based and avoid claiming PLP unless current listing or vendor evidence supports it. The calculator is advisory because real benefit depends on application sync semantics and cache hit behavior.
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, seller claims, controller firmware, IT-mode status, exact board revisions, cable direction, enterprise SSD features and marketplace conditions can change. Verify the exact delivered hardware before deployment.