ZFSCONCEPTS(7)
β¨ zfsconcepts(7) β¨
okay bestie, buckle UP β this is the overview of ZFS concepts, straight out of the Miscellaneous Information Manual. If you've ever wondered what all these ZFS words actually mean, this is your page. π
πΈ NAME πΈ
zfsconcepts β an overview of ZFS concepts, aka the vibe check for your whole storage setup π¦
π DESCRIPTION π
π§ ZFS File System Hierarchy
A ZFS storage pool is a logical collection of devices that provide space for datasets. It's also the root of the ZFS file system hierarchy. Two jobs, one icon. π
You can access the root of the pool as a file system β like mounting and unmounting it, taking snapshots of it, setting properties on it. The physical storage characteristics though? Those are managed by the zpool(8) command. Different department, different girlboss.
See zpool(8) for more info on creating and administering pools. iykyk π
πΈ Snapshots
A snapshot is a read-only copy of a file system or volume. They get created extremely quickly, and initially they consume no additional space within the pool. Then, as data within the active dataset changes, the snapshot starts consuming more data than it would otherwise share with the active dataset. Not me growing in size the second you change things π
Snapshots can have arbitrary names β name it whatever, no rules, main character energy. Snapshots of volumes can be cloned or rolled back, and their visibility is determined by the snapdev property of the parent volume.
File system snapshots are accessible under the .zfs/snapshot directory in the root of the file system. They're automatically mounted on demand and may be unmounted at regular intervals. Whether the .zfs directory is available and visible is controlled by the snapdir property. β¨
π Bookmarks
A bookmark is like a snapshot β a read-only copy of a file system or volume. Compared to snapshots they can be created extremely quickly, and they consume no additional space within the pool. They can also have arbitrary names, much like snapshots. Bestie behavior, honestly.
Unlike snapshots though, bookmarks can not be accessed through the filesystem in any way. Nope, not even a little. From a storage standpoint, a bookmark just provides a way to reference when a snapshot was created as a distinct object. Bookmarks are initially tied to a snapshot β not the filesystem or volume β and they survive even if the snapshot itself is destroyed. And since they're so light weight, there's little incentive to destroy them. They're just vibing. π¦
𧬠Clones
A clone is a writable volume or file system whose initial contents are the same as another dataset. Just like with snapshots, creating a clone is nearly instantaneous, and initially it consumes no additional space.
But here's the tea: clones can only be created from a snapshot. When a snapshot gets cloned, it creates an implicit dependency between the parent and the child. Even if the clone lives somewhere else entirely in the dataset hierarchy, the original snapshot cannot be destroyed as long as a clone exists. The origin property exposes this dependency, and the destroy command lists any such dependencies, if they exist. It's giving "you can't get rid of me that easily." π
You can reverse the clone parent-child dependency relationship by using the promote subcommand. This causes the "origin" file system to become a clone of the specified file system, which makes it possible to destroy the file system that the clone was created from. Slay, plot twist. π₯
π Mount Points
Creating a ZFS file system is a simple operation, so the number of file systems per system is likely to be numerous. To cope with that, ZFS automatically manages mounting and unmounting file systems β no need to go edit /etc/fstab like it's 2009. All automatically managed file systems are mounted by ZFS at boot time. π
By default, file systems are mounted under /path, where path is the name of the file system in the ZFS namespace. Directories are created and destroyed as needed. Effortless.
A file system can also have a mount point set in the mountpoint property. That directory gets created as needed, and ZFS automatically mounts the file system when the zfs mount -a command is invoked β again, without editing /etc/fstab. And because the mountpoint property can be inherited, if pool/home has a mount point of /export/stuff, then pool/home/user automatically inherits a mount point of /export/stuff/user. Generational inheritance, we love to see it. π
A file system mountpoint property of none prevents the file system from being mounted. Simply not participating today. π
If needed, ZFS file systems can also be managed with traditional tools (mount, umount, /etc/fstab). If a file system's mount point is set to legacy, ZFS makes no attempt to manage the file system, and the administrator is responsible for mounting and unmounting it.
β οΈ Because pools must be imported before a legacy mount can succeed, administrators should ensure that legacy mounts are only attempted after the zpool import process finishes at boot time. Fr fr, don't skip this.
For example, on machines using systemd, the mount option
x-systemd.requires=zfs-import.target
will ensure that the zfs-import completes before systemd attempts mounting the filesystem. See systemd.mount(5) for details. π«Ά
ποΈ Deduplication
Deduplication is the process for removing redundant data at the block level, reducing the total amount of data stored. If a file system has the dedup property enabled, duplicate data blocks are removed synchronously. The result? Only unique data is stored, and common components are shared among files. Very efficient of her. β¨
π BUT. Deduplicating data is a very resource-intensive operation. It is generally recommended that you have at least 1.25 GiB of RAM per 1 TiB of storage when you enable deduplication. Calculating the exact requirement depends heavily on the type of data stored in the pool.
Enabling deduplication on an improperly-designed system can result in performance issues (slow I/O and administrative operations). It can potentially lead to problems importing a pool due to memory exhaustion. Deduplication can consume significant processing power (CPU) and memory as well as generate additional disk I/O. This is not a casual little toggle, bestie, this is a commitment. π
Before creating a pool with deduplication enabled, ensure that you have planned your hardware requirements appropriately and implemented appropriate recovery practices, such as regular backups. Consider using the compression property as a less resource-intensive alternative. π
π§ Block cloning
Block cloning is a facility that allows a file (or parts of a file) to be "cloned" β that is, a shallow copy made where the existing data blocks are referenced rather than copied. Later modifications to the data will cause a copy of the data block to be taken and that copy modified. This facility is used to implement "reflinks" or "file-level copy-on-write". It's giving copy-paste but make it β¨structuralβ¨.
Cloned blocks are tracked in a special on-disk structure called the Block Reference Table (BRT). Unlike deduplication, this table has minimal overhead, so it can be enabled at all times. No drama, no RAM crisis. π
Also unlike deduplication, cloning must be requested by a user program. Many common file copying programs, including newer versions of /bin/cp, will try to create clones automatically. Look for "clone", "dedupe" or "reflink" in the documentation for more information. π
There are some limitations to block cloning, and we're listing them all because facts are facts:
- Only whole blocks can be cloned.
- Blocks can not be cloned if they are not yet written to disk.
- Blocks can not be cloned if they are encrypted.
- Blocks can not be cloned if the source and destination
recordsizeproperties differ. - The OS may add additional restrictions β for example, most versions of Linux will not allow clones across datasets. π
and that's the whole page, bestie!! ππβ¨
This one came from OpenZFS, dated October 2, 2024 β go forth and understand your pools, your snapshots, and your clones. You're literally so good at this now. πππ¦
π¦ where this page comes from
- alpine 3.23: zfs-doc 2.4.4-r0 Β· CDDL-1.0
- alpine 3.24: zfs-doc 2.4.4-r0 Β· CDDL-1.0
- nixos 26.05: zfs-user 2.4.4
- nixpkgs unstable: zfs-user 2.4.4
- ubuntu resolute: zfsutils-linux 2.4.1-1ubuntu5 Β· CDDL-1.0
- ubuntu resolute: zfsutils-linux 2.4.1-1ubuntu5.1 Β· CDDL-1.0
- ubuntu stonking: zfsutils-linux 2.4.4-1ubuntu4 Β· CDDL-1.0
- π the page's license: CDDL-1.0
- Copyright (c) 2009 Sun Microsystems, Inc. All Rights Reserved
- Copyright 2011 Joshua M. Clulow <josh@sysmgr.org>
- Copyright (c) 2011, 2019 by Delphix. All rights reserved
- Copyright (c) 2013 by Saso Kiselkov. All rights reserved
- Copyright (c) 2014, Joyent, Inc. All rights reserved
- Copyright (c) 2014 by Adam Stevko. All rights reserved
- Copyright (c) 2014 Integros [integros.com]
- Copyright 2019 Richard Laager. All rights reserved
- Copyright 2018 Nexenta Systems, Inc
- Copyright 2019 Joyent, Inc
- Copyright 2023 Klara, Inc
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms