This page is designed to take you through a brief overview of the ZFS source code. It is not intended as an introduction to ZFS. We assume that you already have some familiarity with common terms and definitions, as well as a general sense of filesystem architecture.
Traditionally, ZFS consists of three main components: ZPL (ZFS POSIX Layer), DMU (Data Management Unit), and SPA (Storage Pool Allocator) as indicated in the above image.
In this picture, you can see the three basic layers, though there are quite a few more elements in each. In addition, we show zvol consumers, as well as the management path, namely zfs(1M) and zpool(1M). You'll find a brief description of all these subsystems below. This is not intended to be an exhaustive overview of exactly how everything works. We hope that this summary tour is easy to follow. If not, feel free to post to the ZFS discussion forum.
These are the basic applications that interact with ZFS solely through the POSIX filesystem APIs. Virtually every application falls into this category. The system calls are passed through the generic OpenSolaris VFS layer to the ZPL.
ZFS provides 'emulated volumes' or volumes or zvols. These volumes are backed by storage from a storage pool, but appear as a normal device under /dev. This is not a typical use case, but there are a small set of cases where this capability is useful. There are a small number of applications that interact directly with these devices, but the most common consumer is a kernel filesystem or target driver layered on top of the device.
A web-based ZFS GUI is available in Solaris 10 releases and on the ZFS storage appliance.
These applications manipulate ZFS file systems or storage pools, including examining properties and dataset hierarchy. While there are some scattered exceptions (zoneadm, zoneadmd, fstyp), the two main applications are zpool(1M) and zfs(1M).
This library provides a Java interface to libzfs and is tailored specifically for the GUI. As such, it is geared primarily toward observability, as the GUI performs most actions through the CLI.
This is the primary interface for management apps to interact with the ZFS kernel module. The library presents a unified, object-based mechanism for accessing and manipulating both storage pools and file systems. The underlying mechanism used to communicate with the kernel is ioctl(2) calls through /dev/zfs.