Skip to main content
StashRaid

Storage Parameters

Usable Capacity

12 TB

Fault Tolerance

4

Array Resilience

Architecture

RAID 5 • Parity

Fault Tolerance

1 Concurrent Failures Allowed

Current Configuration

RAID 5 (Parity)

12 TB Usable

Total RAW: 16 TB

Disk 01DATA
Disk 02DATA
Disk 03DATA
Disk 04PARITY

Total Drives

4 x 4 TB

Efficiency

75% Utilized

Usable: 12 TBWasted to redundancy: 4 TB

Pros & Cons

  • PRO: Good balance of capacity/speed/safety

  • PRO: Cost-effective redundancy

  • CON: Slower writes due to parity calculation

    This setup prioritizes redundancy but has associated performance or capacity costs.

SLOG/ZIL Performance Guide

The ZFS SLOG (Separate Intent Log) is one of the most misunderstood components in a ZFS build. A well-chosen SLOG can transform sync-write performance from abysmal to blazing fast — but the wrong device is worse than none at all. This guide explains how SLOG works, what devices to use, and when it actually matters.

Sync vs Async Writes — The Fundamental Difference

Understanding the difference between synchronous and asynchronous writes is essential to understanding the SLOG. The ZIL (ZFS Intent Log) only comes into play for sync writes — async writes bypass it entirely.

Async Writes

The application writes data and does not wait for a confirmation. Data is buffered in RAM and flushed to disk whenever the kernel decides. This is fast but not crash-safe — if power fails before the flush, data is lost. SMB/CIFS file copies, large sequential transfers, and media streaming are typically async.

Sync Writes

The application writes data and waits for confirmation that the data is safely on stable storage before proceeding. This is essential for databases, NFS, iSCSI, VM datastores, and any workload that requires crash consistency. Without a SLOG, each sync write must commit directly to the spinning HDD pool — often bottlenecking at hundreds of IOPS instead of the hundreds of thousands a SLOG provides.

How the ZIL and SLOG Actually Work

When a sync write arrives, ZFS writes it to the ZIL (in RAM by default, or on the SLOG if one is attached). The application gets its confirmation almost instantly. Meanwhile, the data is also written to the main pool in a transaction group (txg). Once the txg commits (typically every 5 seconds), the ZIL entries for that group are freed and the space is reused.

The 5-Second Transaction Group Cycle

  1. Sync write arrives — written to SLOG (confirmed in microseconds) and queued for the main pool.
  2. Transaction group accumulates — more writes pile up in RAM and on the SLOG over the next ~5 seconds.
  3. TxG commits — the entire batch is written to the main spinning-disk pool as one sequential-ish stream.
  4. ZIL/SLOG space freed — the consumed SLOG capacity is marked reusable.

Key insight: Because ZIL entries are ephemeral — they exist only until the next txg commit — the SLOG never needs much capacity. A 20 GB partition is enough for even the busiest workloads. The performance-critical metric is latency (how fast can the SLOG acknowledge a write?) and endurance (can it survive years of constant sync writes?).

SLOG Device Comparison

Not all SSDs are equal when it comes to SLOG duty. The table below compares the most common options. The critical metrics are write latency (lower is better), endurance (DWPD — Drive Writes Per Day), and power-loss protection (PLP — essential for data safety).

DeviceTypeWrite LatencyEndurance (DWPD)PLPVerdict
Intel Optane 905P / P5800X3D XPoint~5–10 µs60+ DWPDYesGold Standard
NVMe SSD w/ DRAM (Samsung PM9A3, Kioxia CD6)TLC NAND~20–50 µs1–3 DWPDYesExcellent
NVMe SSD DRAM-less (WD SN580, Crucial P3)QLC/TLC NAND~100–300 µs0.1–0.3 DWPDNoNot Recommended
SATA SSD (870 EVO, MX500)TLC NAND~200–500 µs0.3–1 DWPDVariesAvoid for SLOG
RAM disk (emulated)Volatile<1 µsN/ANoGambles Data

When SLOG Helps — and When It Doesn't

SLOG Helps Here

  • NFS datastores — NFS v3/v4 mounts use sync writes by default. A SLOG dramatically improves small-file and metadata-intensive workloads.
  • iSCSI targets — Block-level storage requires crash-safe sync writes. Without a SLOG, iSCSI performance over spinning disks is unusable.
  • VM disk images (VMFS, ZVOLs) — Virtual machines issue frequent fsync/fdatasync calls. A SLOG accelerates VM boot, snapshot, and database operations.
  • Databases (PostgreSQL, MySQL, MariaDB) — Transaction logs rely on sync writes. A fast SLOG reduces query latency by orders of magnitude.
  • NFS-over-RDMA — High-performance fabric storage sees massive gains with an Optane SLOG that keeps up with the wire speed.

SLOG Does Not Help Here

  • SMB/CIFS file transfers — SMB uses async writes by default. The ZIL is never touched, so a SLOG has zero effect.
  • Media streaming / Plex / Jellyfin — Large sequential reads and async writes. No sync I/O, no benefit.
  • Torrent downloads / Usenet — Applications buffer writes and flush asynchronously. A SLOG sits idle.
  • Async-heavy workloads — If your workload is 100% async, adding a SLOG does nothing. Use ARC (RAM cache) tuning instead.
  • All-flash pools — If your main pool is already NVMe, the pool latency is already low. A SLOG may still help for consistency, but the gain is marginal.

SLOG Sizing Guide — You Need Less Than You Think

The golden rule: SLOG needs only 5–20 GB of usable capacity. ZIL writes are ephemeral — they are flushed to the main pool when the transaction group commits (every ~5 seconds). Even under sustained heavy write load, a ZIL rarely holds more than a few gigabytes at any moment.

Home Server / NAS

Recommendation: 16–32 GB Optane 905P or 32 GB enterprise NVMe. Mirrored if you value uptime. More than enough for a few VM disks and NFS shares.

Small Business / Lab

Recommendation: 32–64 GB Optane P5800X or 400 GB enterprise NVMe. Mirror for redundancy. Handles multiple simultaneous NFS clients and database workloads.

Enterprise / Production

Recommendation: 64–128 GB Optane P5800X in mirrored pair. Enterprise NVMe with PLP as fallback. Sizing is driven by concurrent sync write throughput, not capacity.

Real-World Benchmarks

The following benchmarks show 4K random write IOPS for a ZFS pool with and without a SLOG. All tests were conducted with sync writes enabled (via sync=always) on a 6-wide RAIDZ2 pool of 7200 RPM HDDs.

Configuration4K Random Write (IOPS)Latency (µs)Notes
No SLOG (ZIL in RAM)~120 IOPS~8,000 µsBottlenecked by HDD seek latency
SATA SSD SLOG (870 EVO)~1,500 IOPS~650 µsBetter, but SATA queuing limits throughput
NVMe SLOG (Samsung PM9A3)~85,000 IOPS~45 µsExcellent for most workloads
Optane SLOG (P5800X)~450,000 IOPS~8 µsNear-RAM latency, unlimited endurance

For a deeper dive into our testing methodology and tools, see the Performance Testing Methodology page.

Frequently Asked Questions

What is the difference between ZIL and SLOG?

ZIL (ZFS Intent Log) is the in-RAM log that records all sync writes before they are committed to the main pool. SLOG (Separate Intent Log) is a dedicated NVMe/SSD/Optane device that acts as a secondary cache for the ZIL — it absorbs sync writes faster than spinning disks can, then the ZIL flushes to the main pool in the background.

What size SLOG device do I need?

SLOG needs only 5–20 GB of usable capacity. ZIL writes are ephemeral — they are flushed to the main pool as soon as the transaction group commits. A 32 GB or 64 GB Optane drive is more than sufficient for most home and small-business deployments. Spare capacity does not improve performance.

Does SLOG help with SMB file transfers?

Unlikely. SMB typically uses asynchronous writes, which bypass the ZIL entirely. A SLOG device only accelerates synchronous write workloads such as NFS, iSCSI, NFS-over-RDMA, and VM datastores.

Optane vs NVMe SSD for SLOG — which is better?

Intel Optane (3D XPoint) is the gold standard for SLOG due to single-digit microsecond latency and extremely high endurance (60+ DWPD). High-end NVMe SSDs with DRAM and power-loss protection (PLP) are a good second choice. Consumer SATA SSDs without PLP are not recommended — they can corrupt the ZIL during power loss, leading to pool damage.

Does a mirrored SLOG improve performance?

A mirrored SLOG provides redundancy — if one device fails, the pool continues without data loss. Performance is roughly the same as a single device since the ZIL writes to both mirrors in parallel. For production deployments, always mirror your SLOG to avoid a single point of failure.

Try the ZFS Calculator

Estimate real-world performance for your ZFS pool with different SLOG configurations, record sizes, vdev layouts, and drive counts. Compare Optane, NVMe, and HDD-only scenarios side by side.