ZFS basics

From Thomas-Krenn-Wiki
Jump to navigation Jump to search

ZFS (Pseudo-acronym, short for Zettabyte File System) is a file system that has been originally developed by Sun Microsystems for the operating system Solaris. The OpenZFS project develops an Open-Source variant[1]. ZFS distinguishes itself from other file systems through its focus on data integrity, storage capacity, and the management of physical drives within a logical device pool.

Basic function

The main focus of ZFS is on data integrity. To ensure this data integrity, ZFS relies on a transactional approach. This means that writing processes are always completely performed or never[2].

A simple, asynchron writing process collects or buffers data for a determined period in a so-called transaction group (TXG) in the RAM of the system. After this period, the changes are transferred to permanent storage. This completes the transaction.

To ensure data consistency when following this procedure, ZFS uses a Copy-on-Write (CoW) strategy. During a write operation, no blocks are overwritten. Instead, the blocks, with the corresponding changes, are copied to a different location. The old blocks remain intact, but the file system points to the new blocks. If the old blocks are not referenced anymore (for example from Snapshots), they may be overwritten during future write operations.

Setup

Abb. 1: A simplified, illustrative representation of the ZFS storage stack
Image 1: A simplified, illustrative representation of the ZFS storage stack.

To understand the function of ZFS, its building blocks must be understood.

Three levels form the structure of the ZFS storage stack[3] (see image 1): The lowest level are the physical data carriers. These are grouped together in logical units within a storage pool called zpool. Logical objects are provided for the operating system via zpool. In addition to the datasets, that correspond to classic file systems, there are also metadata such as snapshots and bookmarks.

The hardware level is not further explained in this article. If you require consulting on an efficient and performant design of a ZFS infrastructure, do not hesitate to contact us: Contact persons

Furthermore, the Adaptive Replacement Cache (ARC) and the ZFS Intent Log (ZIL) are also important elements for the function of ZFS.

zpool

The zpool is a virtual storage pool that is formed by so-called vdevs (Virtual Devices in brief). ZFS can administrate multiple zpools. The individual zpools are independent from each other and must be administrated separately.

vdev

A vdev is a logical data carrier within a zpools that is created by a physical data carrier or a fusion of multiple physical data carriers. It can be formed by the following entities:

  • physical data carrier
  • data carrier arrays (for example RAID)
  • partitions

In productive environments, a vdev is usually created by individual physical data carriers.

It is also possible to form a vdev out of files. This is an exceptional case and is only recommended for testing purposes.

Storage vdevs are provided for data storage. ZFS provides different redundancy levels for storage vdevs[4]:

  • Single (simple data carrier)
  • Mirror (mirrored data carrier)
  • RAIDZ-1/2/3 (data storage network with 1/2/3 parities)
  • dRAID

In addition, there are further vdevs for special use:

  • Spare: Is used for the failure of a physical data carrier from a storage vdev used for recovery (resilvering)[4]
  • Cache: The read buffer, also known as L2ARC (Level 2 Adaptive Replacement Cache), is an extension of the ARC[4]
  • Log: The so-called SLOG (Separate Intent Log) vdev is responsible for caching during synchronous write operations. It is the relocation of ZIL (ZFS Intent Log)[4]
  • Dedup: This vdev is used for storing the Deduplication Table (DDT) for deduplicate in the zpool
  • Special: Avdev is used for storing metadata and optionally small data blocks. [4]It also stores the DDT if there is no dedicated vdev for it.

Datasets

A dataset forms the upper level of the ZFS Storage Stack. The following datasets can be formed with ZFS:

  • ZVOL: The ZFS Volume is a virtual block device
  • File system: ZFS-native file systems can be set up
  • Clone: A standalone, writable copy of a ZFS snapshot[4]

ZVOLs can be used to insert regular file systems on operating system layers.

Meta data

In addition to data sets, there are further logical objects in ZFS:

  • Snapshot: A snapshot is a momentary representation of a system's state. The blocks described at the time of the snapshot are immutable (immutable) and remain in place at least until the snapshot and its references are deleted[4]
  • Bookmark: A bookmark is a read-only copy of the filesystem or a volume. They are tied to snapshots and are retained even if the snapshot is deleted[4]

ARC and ZIL

In addition to the storage stack, there are two other important modules for using ZFS efficiently.

ARC

The Adaptive Replacement Cache (ARC) is the reading buffer of ZFS. It is formed in the RAM of the host system[5].

The general task of the ARC is to provide blocks for fast reading processes. For this, the ARC builds lists about buffered entries[5]. The ARC distinguishes from most recent (MRU - Most Recently Used) blocks and frequently (MFU - Most Frequently Used) used blocks. Therefore, the ARC is faster as commonly used read buffers that only keep MRU in the buffer[6].

L2ARC

The Level 2 ARC (L2ARC) is formed in the permanent storage (NVMe preferred)[5]. If data is evicted from the ARC, ZFS can store it in the L2ARC and access it during subsequent read operations.

ZIL

The ZFS Intent Log (ZIL) is a temporary cache that is used for synchron writing processes.

The ZIL is not a cache in the strict sense: During a synchronous write operation, the data is written simultaneously to a transaction group (in RAM) and to the ZIL (on physical storage media)[7]. As soon as the data from the transaction group has been fully written to the vdev, the data is rejected in the ZIL. The ZIL is responsible for data integrity even in the event of system failures. Because data must be written to permanent storage, which is slow compared to RAM, synchronous write operations are less efficient.

SLOG

The Separate Intent Log (SLOG) outsources ZIL-blocks to a separate vdev[8]. This is useful, when the data carriers used for the SLOG have a higher writing performance.

More information

Official documentation: OpenZFS Documentation

Basic article: ZFS 101—Understanding ZFS storage and performance

Synchron/Asynchron writing processes: ZFS sync/async + ZIL/SLOG, explained

TrueNAS article on ZIL and SLOG: The ZFS ZIL and SLOG Demystified

ZFS on Linux: https://zfsonlinux.org/

Aaron Toponce about ZFS: ZFS Administration

References

  1. ↑ OpenZFS Documentation (openzfs.github.io, 2026)
  2. ↑ Transactional Semantics (docs.oracle.com, 2026)
  3. ↑ "System Administration" in openzfs Wiki (openzfs.org, 2026)
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 zfsconcepts.7 (openzfs.github.io, 2026)
  5. ↑ 5.0 5.1 5.2 Adaptive Replacement Cache (openzfs.github.io, 2026)
  6. ↑ OpenZFS ARC Source Code (github.com/openzfs, 2026)
  7. ↑ OpenZFS ZIL Source Code (github.com/openzfs, 2026)
  8. ↑ OpenZFS - Synchron Writing Process (openzfs.github.io, 2026)


Author: Stefan Bohn

Stefan Bohn has been employed at Thomas-Krenn.AG since 2020. Originally based in PreSales as a consultant for IT solutions, he moved to Product Management in 2022. There he dedicates himself to knowledge transfer and also drives the Thomas-Krenn Wiki.

Translator: Alina Ranzinger

Alina has been working at Thomas-Krenn.AG since 2024. After her training as multilingual business assistant, she got her job as assistant of the Product Management and is responsible for the translation of texts and for the organisation of the department.