| ZFSPROPS(7) | Miscellaneous Information Manual | ZFSPROPS(7) |
zfsprops — native
and user-defined properties of ZFS datasets
Properties are divided into two types, native properties and user-defined (or "user") properties. Native properties either export internal statistics or control ZFS behavior. In addition, native properties are either editable or read-only. User properties have no effect on ZFS behavior, but you can use them to annotate datasets in a way that is meaningful in your environment. For more information about user properties, see the User Properties section, below.
Every dataset has a set of properties that export statistics about the dataset as well as control various behaviors. Properties are inherited from the parent unless overridden by the child. Some properties apply only to certain types of datasets (file systems, volumes, or snapshots).
The values of numeric properties can be specified using
human-readable suffixes (for example,
k,
KB,
M,
Gb, and so
forth, up to Z
for zettabyte). The following are all valid (and equal) specifications:
1536M, 1.5g,
1.50GB.
The values of non-numeric properties are case sensitive and must be lowercase, except for mountpoint, sharenfs, and sharesmb.
The following native properties consist of read-only statistics about the dataset. These properties can be neither set, nor inherited. Native properties apply to all dataset types unless otherwise noted.
This property can also be referred to by its shortened column name, avail.
zfs set
compression=on
dataset. The default value is
off.-r or
-f options). The roles of origin and clone can be
swapped by promoting the clone with the zfs
promote command.zfs
destroy -d command.
Otherwise, the property is off.zfs
load-key and zfs
unload-key for details). Clones will always share
an encryption key with their origin. See the
Encryption section of
zfs-load-key(8) for details.zfs load-key and
zfs unload-key.This property can also be referred to by its shortened column name, lrefer.
This property can also be referred to by its shortened column name, lused.
zfs receive
-s, this opaque token can be provided to
zfs send
-t to resume and complete the
zfs receive.This property can also be referred to by its shortened column name, refer.
The used space of a snapshot (see the Snapshots section of zfsconcepts(7)) is space that is referenced exclusively by this snapshot. If this snapshot is destroyed, the amount of used space will be freed. Space that is shared by multiple snapshots isn't accounted for in this metric. When a snapshot is destroyed, space that was previously shared with this snapshot can become unique to snapshots adjacent to it, thus changing the used space of those snapshots. The used space of the latest snapshot can also be affected by changes in the file system. Note that the used space of a snapshot is a subset of the written space of the snapshot.
The amount of space used, available, or referenced does not take into account pending changes. Pending changes are generally accounted for within a few seconds. Committing a change to a disk using fsync(2) or O_SYNC does not necessarily guarantee that the space usage information is updated immediately.
zpool "version 13"
pools.ls -l. The amount of space
charged is displayed by du
and ls
-s. See the zfs
userspace command for more information.
Unprivileged users can access only their own space usage. The
root user, or a user who has been granted the userused
privilege with zfs
allow, can access everyone's usage.
The userused@…
properties are not displayed by zfs
get all. The user's name must
be appended after the @ symbol, using one of the
following forms:
Files created on Linux always have POSIX owners.
df -i.
When the property xattr=on is set on a file system additional objects will be created per-file to store extended attributes. These additional objects are reflected in the userobjused value and are counted against the user's userobjquota. When a file system is configured to use xattr=sa no additional internal objects are normally required.
zfs
hold command.ls -l. See the
userused@user property for more
information.
Unprivileged users can only access their own groups' space
usage. The root user, or a user who has been granted the
groupused privilege with zfs
allow, can access all groups' usage.
Unprivileged users can only access their own groups' space
usage. The root user, or a user who has been granted the
groupobjused privilege with
zfs allow, can access
all groups' usage.
chattr
-/+P or zfs project
-s) when being created. The privileged user can
set and change object's project ID via chattr
-p or zfs project
-s anytime. Space is charged to the project of
each file, as displayed by lsattr
-p or zfs project. See the
userused@user property for more
information.
The root user, or a user who has been granted the
projectused privilege with zfs
allow, can access all projects' usage.
The root user, or a user who has been granted the
projectobjused privilege with zfs
allow, can access all projects' objects usage.
This allows us to be more efficient how often we query snapshots. The property is persistent across mount and unmount operations only if the extensible_dataset feature is enabled.
This property can also be referred to by its shortened column name, volblock.
The snapshot may be specified as a short snapshot name (just the part after the @), in which case it will be interpreted as a snapshot in the same filesystem as this dataset. The snapshot may be a full snapshot name (filesystem@snapshot), which for clones may be a snapshot in the origin's filesystem (or the origin of the origin's filesystem, etc.)
The following native properties can be used to change the behavior of a ZFS dataset.
When the property value is set to passthrough, files are created with a mode determined by the inheritable ACEs. If no inheritable ACEs exist that affect the mode, then the mode is set in accordance to the requested mode from the application.
The aclinherit property does not apply to POSIX ACLs.
To obtain the best performance when setting posix users are strongly encouraged to set the xattr=sa property. This will result in the POSIX ACL being stored more efficiently on disk. But as a consequence, all new extended attributes will only be accessible from OpenZFS implementations which support the xattr=sa property. See the xattr property for more details.
zfs
mount -a. Setting this
property to off is similar to setting the
mountpoint property to none, except
that the dataset still has a normal mountpoint property,
which can be inherited. Setting this property to off
allows datasets to be used solely as a mechanism to inherit properties.
One example of setting canmount=off is
to have two datasets with the same mountpoint, so that
the children of both datasets appear in the same directory, but might have
different inherited characteristics.
When set to noauto, a dataset can only be
mounted and unmounted explicitly. The dataset is not mounted
automatically when the dataset is created or imported, nor is it mounted
by the zfs mount
-a command or unmounted by the
zfs unmount
-a command.
This property is not inherited.
The sha512, skein, edonr, and blake3 checksum algorithms require enabling the appropriate features on the pool.
Please see zpool-features(7) for more information on these algorithms.
Changing this property affects only newly-written data.
When set to on (the default), indicates that the current default compression algorithm should be used. The default balances compression and decompression speed, with compression ratio and is expected to work well on a wide variety of workloads. Unlike all other settings for this property, on does not select a fixed compression type. As new compression algorithms are added to ZFS and enabled on a pool, the default compression algorithm may change. The current default compression algorithm is either lzjb or, if the lz4_compress feature is enabled, lz4.
The lz4 compression algorithm is a high-performance replacement for the lzjb algorithm. It features significantly faster compression and decompression, as well as a moderately higher compression ratio than lzjb, but can only be used on pools with the lz4_compress feature set to enabled. See zpool-features(7) for details on ZFS feature flags and the lz4_compress feature.
The lzjb compression algorithm is optimized for performance while providing decent data compression.
The gzip compression algorithm uses the same compression as the gzip(1) command. You can specify the gzip level by using the value gzip-N, where N is an integer from 1 (fastest) to 9 (best compression ratio). Currently, gzip is equivalent to gzip-6 (which is also the default for gzip(1)).
The zstd compression algorithm provides both high compression ratios and good performance. You can specify the zstd level by using the value zstd-N, where N is an integer from 1 (fastest) to 19 (best compression ratio). zstd is equivalent to zstd-3.
Faster speeds at the cost of the compression ratio can be requested by setting a negative zstd level. This is done using zstd-fast-N, where N is an integer in [1-10, 20, 30, …, 100, 500, 1000] which maps to a negative zstd level. The lower the level the faster the compression — 1000 provides the fastest compression and lowest compression ratio. zstd-fast is equivalent to zstd-fast-1.
The zle compression algorithm compresses runs of zeros.
This property can also be referred to by its shortened column name compress. Changing this property affects only newly-written data.
When any setting except off is selected, compression will explicitly check for blocks consisting of only zeroes (the NUL byte). When a zero-filled block is detected, it is stored as a hole and not compressed using the indicated compression algorithm.
Any block being compressed must be no larger than 7/8 of its original size after compression, otherwise the compression will not be considered worthwhile and the block saved uncompressed. Note that when the logical block is less than 8 times the disk sector size this effectively reduces the necessary compression ratio; for example, 8 KiB blocks on disks with 4 KiB disk sectors must compress to 1/2 or less of their original size.
Changing this property only affects newly-written data.
Therefore, set this property at file system creation time by using the
-o
copies=N option.
Remember that ZFS will not import a pool with a missing top-level vdev. Do NOT create, for example a two-disk striped pool and set copies=2 on some datasets thinking you have setup redundancy for them. When a disk fails you will not be able to import the pool and will have lost all of your data.
Encrypted datasets may not have copies=3 since the implementation stores some encryption metadata where the third copy would normally be.
If set to verify, ZFS will do a byte-to-byte comparison in case of two blocks having the same signature to make sure the block contents are identical. Specifying verify is mandatory for the edonr algorithm.
Unless necessary, deduplication should not be enabled on a system. See the Deduplication section of zfsconcepts(7).
Consider setting dnodesize to auto if the dataset uses the xattr=sa property setting and the workload makes heavy use of extended attributes. This may be applicable to SELinux-enabled systems, Lustre servers, and Samba servers, for example. Literal values are supported for cases where the optimal size is known in advance and for performance testing.
Leave dnodesize set to legacy if you need to receive a send stream of this dataset on a pool that doesn't enable the large_dnode feature, or if you need to import this pool on a system that doesn't support the large_dnode feature.
This property can also be referred to by its shortened column name, dnsize.
Selecting encryption=on when creating a dataset indicates that the default encryption suite will be selected, which is currently aes-256-gcm. In order to provide consistent data protection, encryption must be specified at dataset creation time and it cannot be changed afterwards.
For more details and caveats about encryption see the Encryption section of zfs-load-key(8).
Raw keys and hex keys must be 32 bytes long (regardless of the chosen encryption suite) and must be randomly generated. A raw key can be generated with the following command:
# dd
if=/dev/urandom
bs=32 count=1
of=/path/to/output/keyPassphrases must be between 8 and 512 bytes long and will be
processed through PBKDF2 before being used (see the
pbkdf2iters property). Even though the encryption
suite cannot be changed after dataset creation, the keyformat can be
with zfs change-key.
zfs
load-key and zfs
mount -l. This property is
only set for encrypted datasets which are encryption roots. If
unspecified, the default is prompt.
Even though the encryption suite cannot
be changed after dataset creation, the keylocation can be with either
zfs set or
zfs change-key. If
prompt is selected ZFS will ask for the key at the
command prompt when it is required to access the encrypted data (see
zfs load-key for
details). This setting will also allow the key to be passed in via the
standard input stream, but users should be careful not to place keys
which should be kept secret on the command line. If a file URI is
selected, the key will be loaded from the specified absolute file path.
If an HTTPS or HTTP URL is selected, it will be GETted using
fetch(3), libcurl, or nothing,
depending on compile-time configuration and run-time availability. The
SSL_CA_CERT_FILE
environment variable can be set to set the location of the concatenated
certificate store. The
SSL_CA_CERT_PATH
environment variable can be set to override the location of the
directory containing the certificate authority bundle. The
SSL_CLIENT_CERT_FILE
and
SSL_CLIENT_KEY_FILE
environment variables can be set to configure the path to the client
certificate and its key.
zfs
change-key.Before setting this property, a special class vdev must be added to the pool. See zpoolconcepts(7) for more details on the special allocation class.
When the mountpoint property is changed for a file system, the file system and any children that inherit the mount point are unmounted. If the new value is legacy, then they remain unmounted. Otherwise, they are automatically remounted in the new location if the property was previously legacy or none. In addition, any shared file systems are unshared and shared in the new location.
When the mountpoint property is set with
zfs set
-u , the mountpoint property
is updated but dataset is not mounted or unmounted and remains as it was
before.
Quotas cannot be set on volumes, as the volsize property acts as an implicit quota.
Enforcement of user quotas may be delayed by several seconds.
This delay means that a user might exceed their quota before the system
notices that they are over quota and begins to refuse additional writes
with the EDQUOT error message. See the
zfs userspace command
for more information.
Unprivileged users can only access their own groups' space
usage. The root user, or a user who has been granted the
userquota privilege with zfs
allow, can get and set everyone's quota.
This property is not available on volumes, on file systems
before version 4, or on pools before version 15. The
userquota@… properties
are not displayed by zfs
get all. The user's name must
be appended after the @ symbol, using one of the
following forms:
Files created on Linux always have POSIX owners.
Unprivileged users can access only their own groups' space
usage. The root user, or a user who has been granted the
groupquota privilege with zfs
allow, can get and set all groups' quotas.
The root user, or a user who has been granted the
projectquota privilege with zfs
allow, can access all projects' quota.
This property can also be referred to by its shortened column name, rdonly.
For databases that create very large files but access them in small random chunks, these algorithms may be suboptimal. Specifying a recordsize greater than or equal to the record size of the database can result in significant performance gains. Use of this property for general purpose file systems is strongly discouraged, and may adversely affect performance.
The size specified must be a power of two greater than or equal to 512 B and less than or equal to 128 KiB. If the large_blocks feature is enabled on the pool, the size may be up to 1 MiB. See zpool-features(7) for details on ZFS feature flags.
Changing the file system's recordsize affects only files created afterward; existing files are unaffected.
This property can also be referred to by its shortened column name, recsize.
When set to all, ZFS stores an extra copy of all metadata. If a single on-disk block is corrupt, at worst a single block of user data (which is recordsize bytes long) can be lost.
When set to most, ZFS stores an extra copy of most types of metadata. This can improve performance of random writes, because less metadata must be written. In practice, at worst about 1000 blocks (of recordsize bytes each) of user data can be lost if a single on-disk block is corrupt. The exact behavior of which metadata blocks are stored redundantly may change in future releases.
When set to some, ZFS stores an extra copy of only critical metadata. This can improve file create performance since less metadata needs to be written. If a single on-disk block is corrupt, at worst a single user file can be lost.
When set to none, ZFS does not store any copies of metadata redundantly. If a single on-disk block is corrupt, an entire dataset can be lost.
The default value is all.
If refreservation is set, a snapshot is only allowed if there is enough free pool space outside of this reservation to accommodate the current number of "referenced" bytes in the dataset.
If refreservation is set to auto, a volume is thick provisioned (or "not sparse"). refreservation=auto is only supported on volumes. See volsize in the Native Properties section for more information about sparse volumes.
This property can also be referred to by its shortened column name, refreserv.
This property can also be referred to by its shortened column name, reserv.
Please note that the module parameter zfs_disable_prefetch=1 can be used to totally disable speculative prefetch, bypassing anything this property does.
zfs share and
zfs unshare commands. If
the property is set to on, the net(8)
command is invoked to create a
USERSHARE.
Because SMB shares requires a resource name, a unique resource name is constructed from the dataset name. The constructed name is a copy of the dataset name except that the characters in the dataset name, which would be invalid in the resource name, are replaced with underscore (_) characters. Linux does not currently support additional options which might be available on Solaris.
If the sharesmb property is set to off, the file systems are unshared.
The share is created with the ACL (Access Control List) "Everyone:F" ("F" stands for "full permissions", i.e. read and write permissions) and no guest access (which means Samba must be able to authenticate a real user — passwd(5)/shadow(5)-, LDAP- or smbpasswd(5)-based) by default. This means that any additional access control (disallow specific user specific access etc) must be done on the underlying file system.
When the sharesmb property is updated with
zfs set
-u , the property is set to desired value, but
the operation to share, reshare or unshare the the dataset is not
performed.
zfs
share and zfs
unshare commands. If the property is set to
on, the dataset is shared using the default options:
sec=sys,rw,crossmnt,no_subtree_checkPlease note that the options are comma-separated, unlike those found in exports(5). This is done to negate the need for quoting, as well as to make parsing with scripts easier.
See exports(5) for the meaning of the default options. Otherwise, the exportfs(8) command is invoked with options equivalent to the contents of this property.
When the sharenfs property is changed for a dataset, the dataset and any children inheriting the property are re-shared with the new options, only if the property was previously off, or if they were shared before the property was changed. If the new property is off, the file systems are unshared.
When the sharenfs property is updated with
zfs set
-u , the property is set to desired value, but
the operation to share, reshare or unshare the the dataset is not
performed.
zfs upgrade
command.The reservation is kept equal to the volume's logical size to prevent unexpected behavior for consumers. Without the reservation, the volume could run out of space, resulting in undefined behavior or data corruption, depending on how the volume is used. These effects can also occur when the volume size is changed while it is in use (particularly when shrinking the size). Extreme care should be used when adjusting the volume size.
Though not recommended, a "sparse volume" (also
known as "thin provisioned") can be created by specifying the
-s option to the zfs
create -V command, or by
changing the value of the refreservation property (or
reservation property on pool version 8 or earlier)
after the volume has been created. A "sparse volume" is a
volume where the value of refreservation is less than
the size of the volume plus the space required to store its metadata.
Consequently, writes to a sparse volume can fail with
ENOSPC when the pool is low on space. For a
sparse volume, changes to volsize are not reflected in
the refreservation. A volume that is not sparse is
said to be "thick provisioned". A sparse volume can become
thick provisioned by setting refreservation to
auto.
The default value of on enables directory-based extended attributes. This style of extended attribute imposes no practical limit on either the size or number of attributes which can be set on a file. Although under Linux the getxattr(2) and setxattr(2) system calls limit the maximum size to 64K. This is the most compatible style of extended attribute and is supported by all ZFS implementations.
System-attribute-based xattrs can be enabled by setting the value to sa. The key advantage of this type of xattr is improved performance. Storing extended attributes as system attributes significantly decreases the amount of disk I/O required. Up to 64K of data may be stored per-file in the space reserved for system attributes. If there is not enough space available for an extended attribute then it will be automatically written as a directory-based xattr. System-attribute-based extended attributes are not accessible on platforms which do not support the xattr=sa feature. OpenZFS supports xattr=sa on both FreeBSD and Linux.
The use of system-attribute-based xattrs is strongly encouraged for users of SELinux or POSIX ACLs. Both of these features heavily rely on extended attributes and benefit significantly from the reduced access time.
The values on and off are equivalent to the xattr and noxattr mount options.
The following three properties cannot be changed after the file
system is created, and therefore, should be set when the file system is
created. If the properties are not set with the zfs
create or zpool
create commands, these properties are inherited from
the parent dataset. If the parent dataset lacks these properties due to
having been created prior to these features being supported, the new file
system will have the default values for these properties.
The mixed value for the casesensitivity property indicates that the file system can support requests for both case-sensitive and case-insensitive matching behavior. Currently, case-insensitive matching behavior on a file system that supports mixed behavior is limited to the SMB server product. For more information about the mixed value behavior, see the "ZFS Administration Guide".
The casesensitivity, normalization, and utf8only properties are also new permissions that can be assigned to non-privileged users by using the ZFS delegated administration feature.
When a file system is mounted, either through
mount(8) for legacy mounts or the
zfs mount command for normal
file systems, its mount options are set according to its properties. The
correlation between properties and mount options is as follows:
In addition, these options can be set on a
per-mount basis using the -o option, without
affecting the property that is stored on disk. The values specified on the
command line override the values stored in the dataset. The
nosuid option is an alias for
nodevices,nosetuid.
These properties are reported as "temporary" by the
zfs get command. If the
properties are changed while the dataset is mounted, the new setting
overrides any temporary settings.
In addition to the standard native properties, ZFS supports arbitrary user properties. User properties have no effect on ZFS behavior, but applications or administrators can use them to annotate datasets (file systems, volumes, and snapshots).
User property names must contain a colon (":") character to distinguish them from native properties. They may contain lowercase letters, numbers, and the following punctuation characters: colon (":"), dash ("-"), period ("."), and underscore ("_"). The expected convention is that the property name is divided into two portions such as module:property, but this namespace is not enforced by ZFS. User property names can be at most 256 characters, and cannot begin with a dash ("-").
When making programmatic use of user properties, it is strongly suggested to use a reversed DNS domain name for the module component of property names to reduce the chance that two independently-developed packages use the same property name for different purposes.
The values of user properties are arbitrary strings, are always
inherited, and are never validated. All of the commands that operate on
properties (zfs list,
zfs get,
zfs set, and so forth) can
be used to manipulate both native properties and user properties. Use the
zfs inherit command to clear
a user property. If the property is not defined in any parent dataset, it is
removed entirely. Property values are limited to 8192 bytes.
| August 8, 2023 | OpenZFS |