How Does a ZFS Intent Log Restore Confirmed NAS Writes After Power Loss?

A ZFS intent log restores confirmed NAS writes after power loss by keeping a durable record of synchronous operations that ZFS acknowledged before their final data blocks were committed through the normal transaction-group path.

After restart, ZFS can replay those log records and complete the interrupted operations. This preserves the storage promises made to applications, but it does not recover every asynchronous write or repair unrelated hardware and filesystem damage.

What Promise Does a Synchronous Write Make?

A synchronous write asks the storage system not to report success until the operation has a durable recovery record. synchronous writes pass through the ZIL so a client can rely on the acknowledgement after a crash.

Databases, NFS workloads, virtual machines, and applications using fsync may depend on this guarantee. They advance their own transaction state after storage reports that the required write is safe.

Asynchronous writes follow a different promise. They can remain in volatile memory until a later transaction-group commit, so recent unconfirmed changes may disappear after sudden power loss without violating a synchronous durability contract.

How Do the ZIL and Transaction Groups Work Together?

ZFS collects normal dirty data into transaction groups and writes them efficiently to the main pool. The intent log records pending synchronous operations as a short-lived recovery path until the related transaction group is safely committed.

The log is not the permanent home of the file data. Once the transaction group reaches the main storage tree, the earlier intent records are no longer needed and their space can be reused.

This separation lets ZFS preserve low-latency durability for selected writes while still organizing the main pool into larger, more efficient transaction-group commits.

What Happens to the Intent Log After Power Loss?

When the NAS restarts, ZFS imports the pool and checks whether acknowledged synchronous operations were not included in the last committed transaction group. If necessary, the intent log is replayed during recovery.

Replay reissues the logged operations into a new consistent transaction group. The process restores acknowledged writes without requiring applications to guess which confirmed transactions were lost.

The recovery scope is deliberately small because the log covers recent synchronous operations, not the entire pool. ZFS still relies on its committed copy-on-write tree for the broader filesystem state.

What Changes When the ZIL Uses a Separate SLOG Device?

Every pool has an intent-log mechanism, but an optional separate log device moves its durable records away from the main data vdevs. A low-latency SLOG can shorten sync commits when the main pool is slower at persisting small forced writes.

The SLOG is not a general write cache and is normally not read during healthy operation. The main transaction groups still write the authoritative data to the regular pool.

A fast SLOG helps only workloads that issue meaningful synchronous writes. Media streaming, ordinary reads, and mostly asynchronous file copies may show little or no benefit.

Why Do Power-Loss Protection and Latency Matter More Than Capacity?

An intent-log device needs to preserve acknowledged records when the system loses power. power-loss protection preserves SLOG writes that might otherwise remain only in volatile device cache.

Sustained small-write latency and flush behavior matter more than large advertised capacity. The active log generally covers a short window of pending synchronous operations rather than serving as a large long-term data tier.

A slow or dishonest device can make synchronous writes slower or undermine the durability promise. Consumer SSD burst benchmarks do not prove safe forced-write behavior during an outage.

What Can an Intent Log Not Recover?

The intent log cannot recreate asynchronous writes that were never promised durable, reverse an intentional overwrite, or replace an independent backup copy after every online version is damaged.

It also cannot correct bad RAM, controller firmware bugs, dishonest drive flushes, failed pool members beyond redundancy, or application corruption already committed as a valid new state.

A UPS, correct write ordering, checksums, snapshots, redundancy, and backups address other failure boundaries. The ZIL specifically preserves acknowledged synchronous intent across an interruption.

FAQ

Is the SLOG the same thing as the ZIL?

No. The ZIL is the ZFS intent-log mechanism. A SLOG is an optional separate device used to store those intent records instead of placing them on the main pool.

Does a SLOG speed every NAS write?

No. It mainly affects synchronous writes whose latency is limited by durable log commits. Asynchronous writes and read workloads may not improve.

Is the ZIL read during normal operation?

Normally it is not used as the source of file reads. It is replayed after an interruption when confirmed synchronous operations were not included in the last committed transaction group.

Does ZFS need an intent log to remain filesystem-consistent?

ZFS copy-on-write transaction groups preserve a consistent committed tree. The intent log adds recovery of acknowledged synchronous operations that occurred after that committed point.

Final Takeaway

A ZFS intent log does not accelerate every kind of recovery. Its precise job is to preserve and replay confirmed synchronous operations that had not yet reached the main transaction group. A low-latency, power-loss-protected SLOG can make those commits faster, while backups, redundancy, checksums, snapshots, and a UPS continue protecting different failure boundaries.