Properties are an important part of determining and setting the configuration of ZFS storage systems. They can also be used to review the performance and usage of storage resources. Properties can be set at a top-level and inherited by child components when created. Understanding how ZFS properties are utilized is important to operating an efficient storage system.
In this article, we will explore how to properties work and how to get and set properties.
Learning Objectives
- Learn how properties and their inheritance are used in ZFS.
- Learn how to set properties to change the configuration of a storage system.
- Learn how to get information from properties.
This article is one of a series of articles on ZFS. You can start at the beginning by creating a ZFS playground on which you can play.
ZFS Properties
Properties are essential to the operation of ZFS. Up to this point, we have not spent much time using them. We used simple commands in earlier articles to create and configure storage pools. To enable compression and deduplication, we set some properties to enable those features on an existing storage pool. Each time we created a new pool or enabled some feature, properties were being set and inherited, sometimes without our direct manipulation. Properties are used consistently in ZFS to provide information to the storage administrator or to allow the administrator to change the behavior of the storage system.
There are two types of properties. Those that are integrated directly into ZFS are “native” properties. Properties that are named and used by storage administrators are “user-defined” properties. Native properties provide information, such as statistics and usage, and allow the storage administrator to configure the storage system. Some native properties are dataset-specific. Native properties have access to information on the internal operations and state of the ZFS system. Properties created and used by a storage administrator allow for annotation, customization, and automation of the storage system and its components by processes outside of ZFS. User properties do not affect the behavior or configuration of ZFS.
ZFS properties are inherited. When you create a new filesystem, volume, or snapshot under a pool or another dataset, the new dataset will have the same properties from its parent. You can override those properties as needed. This might be important for example when you have a user requirement for a filesystem-specific configuration, such as enabling a high-level of compression for archival purposes.
When you need to override a ZFS property, it’s helpful to know which ones are read-only and which are writable. Generally, properties that provide statistical information are read-only. Properties that affect the operation of a storage system are writable in order to change the behavior. We will look at how to determine if a property can be changed later with some examples.
Getting ZFS Properties
Before we start changing properties, it would be helpful to know what properties exist. For this, we can get a list of all available properties for a specific dataset or storage pool using the zfs(8) or zpool(8) commands. We use the zfs get or zpool get commands to see the status of properties. We also need to name the dataset or storage pool for which we want to see the properties.
To see all of the zfs properties our “mypool” storage pool example, use the following command:
To see all of the zpool properties for the pool, use the following command:
If you are only interested in a specific property, you can examine it by using its name. We can determine if compression is enabled by looking at the compression property .
We can determine that compression is enabled because the compression algorithm lz4 is listed for the property.
If you want to know how well the storage system is performing, there are various properties that provide that information. When you use compression for a storage pool, you might want to know the “compressability” of the data being stored. The compressratio property will show how much compression is taking place for the data in the storage system.
You may want to know how much data has been used in the storage system. There are three useful properties to examine use by the dataset, snapshots, and child datasets.
There are many properties as you saw in the first examples when you list all of the properties. The native properties are documented in the zfs(8) and zpool(8) manual pages.
Setting ZFS Properties
Enabling specific behavior requires setting or changing a ZFS property. Much like the zfs get command, zfs set is used to assign a value to a specific property. Once you identify the property that should change, you issue the set command with the property name and its intended value. Remember, that only read-write properties can be changed.
As we did in a previous article, you can enable the deduplication features for a ZFS storage pool using this example:
# zfs set dedup=on mypool
Once a property is set to a value, it will remain in that state through reboots.
However, there are three properties that cannot be changed once set. These properties are related to file names and include case sensitivity (casesensitivity), unicode normalization (normalization), and UTF-8 required (utf8only). These properties have to be set when the file system is created using the zfs create or zpool create commands and cannot be changed later.
# zfs create -o casesensitivity=insensitive -o normalization=formC mypool/myfs
As this example shows, multiple properties can be passed during the creation of a file system. The created mypool/myfs file system will have file name case insensitivity and use a specific method for file name normalization. These properties can no longer be changed for mypool/myfs.
Using User Properties
ZFS allows storage administrators to create their own properties. User-defined properties do not affect the configuration or behavior of ZFS, but they do allow administrators to make notes about datasets or programmatically automate aspects of storage administration. This feature can be helpful for a group of storage administrators that need to “embed” documentation along with the creation of datasets. For example, the owner and classification of a dataset can be listed in user properties instead of only being maintained separately. Scripts can set and use user properties as configuration data for automating maintenance tasks.
There are several requirements for the names of your user properties. In order to distinguish native properties from user properties, a colon (“:”) is needed for the user property name. There is also a convention of using a reverse DNS domain name to make the user properties unique to the organization implementing the user property. For example, I might use the following user property to define the owner of a file system at my organization.
# zfs set com.ikawnoclast:owner=smythe mypool/finance
You can also create a user property for a snapshot that might annotate when the snapshot was created.
# zfs snapshot -o com.ikawnoclast:expires_on="$(date -v+30d)" mypool/myfs@mysnap
This allows you to attach an expiration date (30 days in the future) to the snapshot as it was taken. This value would be useful to the storage administrator or any scripts developed to automate management of the storage system.
Next Time
In the next article, we will look at managing access control and delegation in ZFS.
ikawnoclastic thoughts 