ZFS is an advanced file system designed to solve major problems found in previous storage subsystem software. Show
Originally developed at Sun™, ongoing open source ZFS development has moved to the OpenZFS Project. ZFS has three major design goals:
21.1. What Makes ZFS DifferentMore than a file system, ZFS is fundamentally different from traditional file systems. Combining the traditionally separate roles of volume manager and file system provides ZFS with unique advantages. The file system is now aware of the underlying structure of the disks. Traditional file systems could exist on a single disk alone at a time. If there were two disks then creating two separate file systems was necessary. A traditional hardware RAID configuration avoided this problem by presenting the operating system with a single logical disk made up of the space provided by physical disks on top of which the operating system placed a file system. Even with software RAID solutions like those provided by GEOM, the UFS file system living on top of the RAID believes it’s dealing with a single device. ZFS' combination of the volume manager and the file system solves this and allows the creation of file systems that all share a pool of available storage. One big advantage of ZFS' awareness of the physical disk layout is that existing file systems grow automatically when adding extra disks to the pool. This new space then becomes available to the file systems. ZFS can also apply different properties to each file system. This makes it useful to create separate file systems and datasets instead of a single monolithic file system. 21.2. Quick Start GuideFreeBSD can mount ZFS pools and datasets during system initialization. To enable it, add this line to /etc/rc.conf: Then start the service: The examples in this section assume three SCSI disks with the device names da0, da1, and da2. Users of SATA hardware should instead use ada device names. 21.2.1. Single Disk PoolTo create a simple, non-redundant pool using a single disk device:
To view the new pool, review the output
of
This output shows creating and mounting of the
This pool is not using any advanced ZFS features and properties yet. To create a dataset on this pool with compression enabled:
The Disable compression with:
To unmount a file system, use
To re-mount the file system to make it accessible again, use
Running
Use ZFS datasets like any file system after creation. Set other available features on a per-dataset basis when needed. The example below creates a new file system called
Use
Notice that all file systems in the pool have the same available space. Using To destroy the file systems and then the pool that is no longer needed:
21.2.2. RAID-ZDisks fail. One way to avoid data loss from disk failure is to use RAID. ZFS supports this feature in its pool design. RAID-Z pools require three or more disks but provide more usable space than mirrored pools. This example creates a RAID-Z pool, specifying the disks to add to the pool:
The previous example created the
Enable compression and store an extra copy of directories and files:
To make this the new home directory for users, copy the user data to this directory and create the appropriate symbolic links:
Users data is now stored on the freshly-created /storage/home. Test by adding a new user and logging in as that user. Create a file system snapshot to roll back to later:
ZFS creates snapshots of a dataset, not a single directory or file. The
To list all available snapshots, run
Write a script to take regular snapshots of user data. Over time, snapshots can use up a lot of disk space. Remove the previous snapshot using the command:
After testing, make /storage/home the real /home with this command:
Run
This completes the RAID-Z configuration. Add daily status updates about the created file systems to the nightly periodic(8) runs by adding this line to /etc/periodic.conf: daily_status_zfs_enable="YES" 21.2.3. Recovering RAID-ZEvery software RAID has a method of monitoring its If all pools are Online and everything is normal, the message shows: If there is a problem, perhaps a disk being in the Offline state, the pool state will look like this:
"OFFLINE" shows the administrator took da1 offline using:
Power down the computer now and replace da1. Power up the computer and return da1 to the pool:
Next, check the status again, this time without
In this example, everything is normal. 21.2.4. Data VerificationZFS uses checksums to verify the integrity of stored data. Creating file systems automatically enables them.
Verifying the data checksums (called scrubbing) ensures integrity of the The duration of a scrub depends on the amount of data stored. Larger amounts of data will take proportionally longer to verify. Since scrubbing is I/O intensive, ZFS allows a single scrub to run at a time. After scrubbing completes, view the status with
Displaying the completion date of the last scrubbing helps decide when to start another. Routine scrubs help protect data from silent corruption and ensure the integrity of the pool. 21.3. zpool AdministrationZFS administration uses two main utilities. The 21.3.1. Creating and Destroying Storage PoolsCreating a ZFS storage pool requires permanent decisions, as the pool structure cannot change after creation. The most important decision is which types of vdevs to group the physical disks into. See the list of vdev types for details about the possible options. After creating the pool, most vdev types do not allow adding disks to the vdev. The exceptions are mirrors, which allow adding new disks to the vdev, and stripes, which upgrade to mirrors by attaching a new disk to the vdev. Although adding new vdevs expands a pool, the pool layout cannot change after pool creation. Instead, back up the data, destroy the pool, and recreate it. Create a simple mirror pool:
To create more than one vdev with a single command, specify groups of disks separated by the
vdev type keyword,
Pools can also use partitions rather than whole disks. Putting ZFS in a separate partition allows the same disk to have other partitions for other purposes. In particular, it allows adding partitions with bootcode and file systems needed for booting. This allows booting from disks that are also members of a pool. ZFS adds no performance penalty on FreeBSD when using a partition rather than a whole disk. Using partitions also allows the administrator to under-provision the disks, using less than the full capacity. If a future replacement disk of the same nominal size as the original actually has a slightly smaller capacity, the smaller partition will still fit, using the replacement disk. Create a RAID-Z2 pool using partitions:
Destroy a pool that is no longer needed to reuse the
disks. Destroying a pool requires unmounting the file systems in that pool first. If any dataset is in use, the unmount operation fails without destroying the pool. Force the pool destruction with 21.3.2. Adding and Removing DevicesTwo ways exist for adding
disks to a pool: attaching a disk to an existing vdev with A pool created with a single disk lacks redundancy. It can detect corruption but can not repair it, because there is no other copy of the data. The
copies property may be able to recover from a small failure such as a bad sector, but does not provide the same level of protection as mirroring or RAID-Z. Starting with a pool consisting of a single disk vdev, use Upgrade the single disk (stripe) vdev ada0p3 to a mirror by attaching ada1p3:
When adding disks to the existing vdev is not an option, as for RAID-Z, an alternative method is to add another vdev to the pool. Adding vdevs provides higher performance by distributing writes across the vdevs. Each vdev provides its own
redundancy. Mixing vdev types like ZFS stripes data across each of the vdevs. For example, with two mirror vdevs, this is effectively a RAID 10 that stripes writes across two sets of mirrors. ZFS allocates space so that each vdev reaches 100% full at the same time. Having vdevs with different amounts of free space will lower performance, as more data writes go to the less full vdev. When attaching new devices to a boot pool, remember to update the bootcode. Attach a second mirror group (ada2p3 and ada3p3) to the existing mirror:
Removing vdevs from a pool is impossible and removal of disks from a mirror is exclusive if there is enough remaining redundancy. If a single disk remains in a mirror group, that group ceases to be a mirror and becomes a stripe, risking the entire pool if that remaining disk fails. Remove a disk from a three-way mirror group:
21.3.3. Checking the Status of a PoolPool status is important. If a drive goes offline or ZFS detects a
read, write, or checksum error, the corresponding error count increases. The
21.3.4. Clearing ErrorsWhen detecting an error, ZFS increases the read, write, or checksum error counts. Clear the error message and reset the counts with 21.3.5. Replacing a Functioning DeviceIt may be desirable to replace one disk with a different disk. When replacing a working disk, the process keeps the old disk online during the replacement. The pool never enters a degraded state, reducing the risk of data loss. Running Replace a functioning device in the pool:
21.3.6. Dealing with Failed DevicesWhen a disk in a pool fails, the vdev to which the disk belongs enters the degraded state. The data is still available, but with reduced performance because ZFS computes missing data from the available redundancy. To restore the vdev to a fully functional state, replace the failed physical device. ZFS is then instructed to begin the resilver operation. ZFS recomputes data on the failed device from available redundancy and writes it to the replacement device. After completion, the vdev returns to online status. If the vdev does not have any redundancy, or if devices have failed and there is not enough redundancy to compensate, the pool enters the faulted state. Unless enough devices can reconnect the pool becomes inoperative requiring a data restore from backups. When replacing a failed disk, the name of the failed disk changes to the GUID of the new disk. A new device name parameter for Replace a
failed disk using
21.3.7. Scrubbing a PoolRoutinely scrub pools, ideally at least once every month. The
To cancel a scrub operation if needed, run 21.3.8. Self-HealingThe checksums stored with data blocks enable the file system to self-heal. This feature will automatically repair data whose checksum does not match the one recorded on another device that is part of the storage pool. For example, a mirror configuration with two disks where one drive is starting to malfunction and cannot properly store the data any more. This is worse when the data was not accessed for a long time, as with long term archive storage. Traditional file systems need to run commands that check and repair the data like fsck(8). These commands take time, and in severe cases, an administrator has to decide which repair operation to perform. When ZFS detects a data block with a mismatched checksum, it tries to read the data from the mirror disk. If that disk can provide the correct data, ZFS will give that to the application and correct the data on the disk with the wrong checksum. This happens without any interaction from a system administrator during normal pool operation. The next example shows this self-healing behavior by creating a mirrored pool of disks /dev/ada0 and /dev/ada1.
Copy some important data to the pool to protect from data errors using the self-healing feature and create a checksum of the pool for later comparison.
Simulate data corruption by writing random data to the beginning of one of the disks in the mirror. To keep ZFS from healing the data when detected, export the pool before the corruption and import it again afterwards.
The pool status shows that one device has experienced an error. Note that applications reading data from the pool did not receive any incorrect data. ZFS provided data from the ada0 device with the correct checksums. To find the device with the wrong checksum, look for one whose
ZFS detected the error and handled it by using the redundancy present in the unaffected ada0 mirror disk. A checksum comparison with the original one will reveal whether the pool is consistent again.
Generate checksums before and after the intentional tampering while the pool data still matches. This shows how ZFS is capable of detecting and correcting any errors automatically when the checksums differ. Note this is possible with enough redundancy present in the pool. A pool consisting of a single device has no self-healing capabilities. That is also the reason why checksums are so important in ZFS; do not disable them for any reason. ZFS requires no fsck(8) or similar file system consistency check program to detect and correct this, and keeps the pool available while there is a problem. A scrub operation is now required to overwrite the corrupted data on ada1.
The scrub operation reads data from
ada0 and rewrites any data with a wrong checksum on ada1, shown by the
After the scrubbing operation completes with all the data synchronized from ada0 to ada1, clear the error messages from the pool status by running
The pool is now back to a fully working state, with all error counts now zero. 21.3.9. Growing a PoolThe smallest device in each vdev limits the usable size of a redundant pool. Replace the smallest device with a larger device. After completing a replace or resilver operation, the pool can grow to use the capacity of the new device. For example, consider a mirror of a 1 TB drive and a 2 TB drive. The usable space is 1 TB. When replacing the 1 TB drive with another 2 TB drive, the resilvering process copies the existing data onto the new drive. As both of the devices now have 2 TB capacity, the mirror’s available space grows to 2 TB. Start expansion by using 21.3.10. Importing and Exporting PoolsExport pools before moving them to another system. ZFS unmounts all datasets, marking each
device as exported but still locked to prevent use by other disks. This allows pools to be imported on other machines, other operating systems that support ZFS, and even different hardware architectures (with some caveats, see zpool(8)). When a dataset has open files, use Export a pool that is not in use: Importing a pool automatically mounts the datasets. If this is undesired behavior, use List all available pools for import:
Import the pool with an alternative root directory:
21.3.11. Upgrading a Storage PoolAfter upgrading FreeBSD, or if importing a pool from a system using an older version, manually upgrade the pool to the latest ZFS version to support newer features. Consider whether the pool may ever need importing on an older system before upgrading. Upgrading is a one-way process. Upgrade older pools is possible, but downgrading pools with newer features is not. Upgrade a v28 pool to support
The newer features of ZFS will not be available until Upgrade a pool to support new feature flags:
21.3.12. Displaying Recorded Pool HistoryZFS records commands that change the pool, including creating datasets, changing properties, or replacing a disk. Reviewing history about a pool’s creation is useful, as is checking which user performed a specific action and when. History is not kept in a log file, but is part of the
pool itself. The command to review this history is aptly named
The output shows
Show more details by adding
The output shows that the Combine both options to 21.3.13. Performance MonitoringA built-in monitoring system can display pool I/O statistics in real time. It shows the amount of free and used space on the pool, read and write operations performed per second, and I/O bandwidth used. By default, ZFS monitors and displays all pools in the system. Provide a pool name to limit monitoring to that pool. A basic example:
To continuously see I/O activity, specify a number as the last parameter, indicating an interval in seconds to wait between updates. The next statistic line prints after each interval. Press Ctrl+C to stop this continuous monitoring. Give a second number on the command line after the interval to specify the total number of statistics to display. Display even more detailed I/O statistics with
21.3.14. Splitting a Storage PoolZFS can split a pool consisting of one or more mirror vdevs into two pools. Unless otherwise specified, ZFS detaches the
last member of each mirror and creates a new pool containing the same data. Be sure to make a dry run of the operation with 21.4. zfs AdministrationThe 21.4.1. Creating and Destroying DatasetsUnlike traditional disks and volume managers, space in ZFS is not preallocated. With traditional file systems, after
partitioning and assigning the space, there is no way to add a new file system without adding a new disk. With ZFS, creating new file systems is possible at any time. Each dataset has properties including features like compression, deduplication, caching, and quotas, as well as other useful properties like readonly, case sensitivity, network file sharing, and a mount point. Nesting datasets
within each other is possible and child datasets will inherit properties from their ancestors. Delegate, replicate, snapshot, jail
allows administering and destroying each dataset as a unit. Creating a separate dataset for each different type or set of files has advantages. The drawbacks to having a large number of datasets are that some commands like
Destroying a dataset is much quicker than deleting the files on the dataset, as it does not involve scanning the files and updating the corresponding metadata. Destroy the created dataset:
In modern versions of ZFS, 21.4.2. Creating and Destroying VolumesA volume is a special dataset type. Rather than mounting as a file system, expose it as a block device under /dev/zvol/poolname/dataset. This allows using the volume for other file systems, to back the disks of a virtual machine, or to make it available to other network hosts using protocols like iSCSI or HAST. Format a volume with any file system or without a file system to store raw data. To the user, a volume appears to be a regular disk. Putting ordinary file systems on these zvols provides features that ordinary disks or file systems do not have. For example, using the compression property on a 250 MB volume allows creation of a compressed FAT file system.
Destroying a volume is much the same as destroying a regular file system dataset. The operation is nearly instantaneous, but it may take minutes to reclaim the free space in the background. 21.4.3. Renaming a DatasetTo change the name of a dataset, use Rename a dataset and move it to be under a different parent dataset:
Renaming snapshots uses the same command. Due to the nature of snapshots, rename cannot change their parent dataset. To rename a recursive snapshot, specify
21.4.4. Setting Dataset PropertiesEach ZFS dataset has properties that control its behavior. Most properties are automatically inherited from the parent dataset, but can be overridden locally. Set a property on a dataset with
To remove a custom property, use
Two commonly used and useful dataset properties are the NFS and SMB share options. Setting these defines if and how ZFS shares datasets on the network. At present, FreeBSD supports setting NFS sharing alone. To get the current status of a share, enter:
To enable sharing of a dataset, enter:
Set other options for sharing datasets through NFS, such as
21.4.5. Managing SnapshotsSnapshots are one of the most powerful features of ZFS. A snapshot provides a read-only, point-in-time copy of the dataset. With Copy-On-Write (COW), ZFS creates
snapshots fast by preserving older versions of the data on disk. If no snapshots exist, ZFS reclaims space for future use when data is rewritten or deleted. Snapshots preserve disk space by recording just the differences between the current dataset and a previous version. Allowing snapshots on whole datasets, not on individual files or directories. A snapshot from a dataset duplicates everything contained in it. This includes the file system properties, files, directories, permissions, and so
on. Snapshots use no extra space when first created, but consume space as the blocks they reference change. Recursive snapshots taken with Snapshots in ZFS provide a variety of features that even other file systems with snapshot functionality lack. A typical example of snapshot use is as a quick way of backing up the current state of the file system when performing a risky action like a software installation or a system upgrade. If the action fails, rolling back to the snapshot returns the system to the same state when creating the snapshot. If the upgrade was successful, delete the snapshot to free up space. Without snapshots, a failed upgrade often requires restoring backups, which is tedious, time consuming, and may require downtime during which the system is unusable. Rolling back to snapshots is fast, even while the system is running in normal operation, with little or no downtime. The time savings are enormous with multi-terabyte storage systems considering the time required to copy the data from backup. Snapshots are not a replacement for a complete backup of a pool, but offer a quick and easy way to store a dataset copy at a specific time. 21.4.5.1. Creating SnapshotsTo create snapshots, use Create a recursive snapshot of the entire pool:
Snapshots are not shown by a normal Snapshots are not mounted directly, showing no path in the
Displaying both the dataset and the snapshot together reveals how snapshots work in COW fashion. They save the changes (delta) made and not the complete file system contents all over again. This means that snapshots take little space when making changes. Observe space usage even more by copying a file to the dataset, then creating a second snapshot:
The second snapshot contains the changes to the dataset after the copy operation. This yields enormous space
savings. Notice that the size of the snapshot 21.4.5.2. Comparing SnapshotsZFS provides a built-in command to compare the differences in content between two snapshots. This is helpful with a lot of snapshots taken over time when the
user wants to see how the file system has changed over time. For example,
The command lists the changes between the specified snapshot (in this case
Comparing the output with the table, it becomes clear that ZFS added passwd after creating the snapshot Comparing two snapshots is helpful when using the ZFS replication feature to transfer a dataset to a different host for backup purposes. Compare two snapshots by providing the full dataset name and snapshot name of both datasets:
A backup administrator can compare two snapshots received from the sending host and determine the actual changes in the dataset. See the Replication section for more information. 21.4.5.3. Snapshot RollbackWhen at least one snapshot is
available, roll back to it at any time. Most often this is the case when the current state of the dataset is no longer and if preferring an older version. Scenarios such as local development tests gone wrong, botched system updates hampering the system functionality, or the need to restore deleted files or directories are all too common occurrences. To roll back a snapshot, use In the first example, roll back a snapshot because of a careless
At this point, the user notices the removal of extra files and wants them back. ZFS provides an easy way to get them back using rollbacks, when performing snapshots of important data on a regular basis. To get the files back and start over from the last snapshot, issue the command:
The rollback operation restored the dataset to the state of the last snapshot. Rolling back to a snapshot taken much earlier with other snapshots taken afterwards is also possible. When trying to do this, ZFS will issue this warning:
This warning means that snapshots exist between the current state of the dataset and the snapshot to which the user wants to roll
back. To complete the rollback delete these snapshots. ZFS cannot track all the changes between different states of the dataset, because snapshots are read-only. ZFS will not delete the affected snapshots unless the user specifies
The output from 21.4.5.4. Restoring Individual Files from SnapshotsSnapshots live in a hidden directory under the parent dataset: .zfs/snapshots/snapshotname. By default, these directories will not show even when executing a standard
Restore individual files to a previous state by copying them from the snapshot back to the parent dataset. The directory structure below .zfs/snapshot has a directory named like the snapshots taken earlier to make it easier to identify them. The next example shows how to restore a file from the hidden .zfs directory by copying it from the snapshot containing the latest version of the file:
Even if the
The error reminds the user that snapshots are read-only and cannot change after creation. Copying files into and removing them from snapshot directories are both disallowed because that would change the state of the dataset they represent. Snapshots consume space based on how much the parent file system has changed since the time of the snapshot. The To destroy snapshots and reclaim the space, use 21.4.6. Managing ClonesA clone is a copy of a snapshot treated more like a regular dataset. Unlike a snapshot, a clone is writeable and mountable, and has its own properties. After creating a clone using To show the clone feature use this example dataset:
A typical use for clones is to experiment with a specific dataset while keeping the snapshot around to fall back to in case something goes wrong. Since snapshots cannot change, create a read/write clone of a snapshot. After achieving the desired result in the clone, promote the clone to a dataset and remove the old file system. Removing the parent dataset is not strictly necessary, as the clone and dataset can coexist without problems.
Creating a clone makes it an exact copy of the state the dataset as it was when taking the snapshot. Changing the clone independently from its originating
dataset is possible now. The connection between the two is the snapshot. ZFS records this connection in the property
After making some changes like copying loader.conf to the promoted clone, for example, the old directory becomes obsolete in
this case. Instead, the promoted clone can replace it. To do this,
The cloned snapshot is now an ordinary dataset. It contains all the data from the original snapshot plus the files added to it like loader.conf. Clones provide useful features to ZFS users in different scenarios. For example, provide jails as snapshots containing different sets of installed applications. Users can clone these snapshots and add their own applications as they see fit. Once satisfied with the changes, promote the clones to full datasets and provide them to end users to work with like they would with a real dataset. This saves time and administrative overhead when providing these jails. 21.4.7. ReplicationKeeping data
on a single pool in one location exposes it to risks like theft and natural or human disasters. Making regular backups of the entire pool is vital. ZFS provides a built-in serialization feature that can send a stream representation of the data to standard output. Using this feature, storing this data on another pool connected to the local system is possible, as is sending it over a network to another system. Snapshots are the basis for this replication (see the section on
ZFS snapshots). The commands used for replicating data are These examples show ZFS replication with these two pools:
The pool named mypool is the primary pool where writing and reading data happens on a regular basis. Using a second standby pool backup in case the primary pool becomes unavailable. Note that this fail-over is not done automatically by ZFS, but must be manually done by a system administrator when needed. Use a snapshot to provide a consistent file system version to replicate. After creating a snapshot of mypool, copy it to the backup pool by replicating snapshots. This does not include changes made since the most recent snapshot.
Now that a snapshot exists, use
To back up a dataset with
The Instead of storing the backups as archive files, ZFS can receive them as a live file system, allowing direct access to the backed up data. To get to the actual data contained in those streams, use
21.4.7.1. Incremental Backups
Create a second snapshot called replica2. This second snapshot contains changes made to the file system between now and the previous snapshot, replica1. Using
The incremental stream replicated the changed data rather than the entirety of replica1. Sending the differences alone took much less time to transfer and saved disk space by not copying the whole pool each time. This is useful when replicating over a slow network or one charging per transferred byte. A new file system, backup/mypool, is available with the files and data from the pool mypool. Specifying 21.4.7.2. Sending Encrypted Backups over SSHSending streams over the network is a good way to keep a remote backup, but it does come with a drawback. Data sent over the network link is not encrypted, allowing anyone to intercept and transform the streams back into data without the knowledge of the sending user. This is undesirable when sending the streams over the internet to a remote host. Use SSH to securely encrypt data sent over a network connection. Since ZFS requires redirecting the stream from standard output, piping it through SSH is easy. To keep the contents of the file system encrypted in transit and on the remote system, consider using PEFS. Change some settings and take security precautions first. This describes the necessary steps required for the Change the configuration as follows:
On the receiving system: +
The unprivileged user can receive and mount datasets now, and replicates the home dataset to the remote system:
Create a recursive snapshot called monday of the file system dataset home on the pool mypool. Then 21.4.8. Dataset, User, and Group QuotasUse Dataset quotas to restrict the amount of space consumed by a particular dataset. Reference Quotas work in much the same way, but count the space used by the dataset itself, excluding snapshots and child datasets. Similarly, use user and group quotas to prevent users or groups from using up all the space in the pool or dataset. The following examples assume that the users already exist in the system. Before adding a user to the system, make sure to create their home dataset first and set the To enforce a dataset quota of 10 GB for storage/home/bob:
To enforce a reference quota of 10 GB for storage/home/bob:
To remove a quota of 10 GB for storage/home/bob:
The general format is
For example, to enforce a user quota of 50 GB for the user named joe:
To remove any quota:
The general format for setting a group quota is: To set the quota for the group firstgroup to 50 GB, use:
To remove the quota for the group firstgroup, or to make sure that one is not set, instead use:
As with the user quota property, non- To display the amount of space used by each user on a file system or snapshot along with any quotas, use Privileged users and
21.4.9. ReservationsReservations guarantee an always-available amount of space on a dataset. The reserved space will not be available to any other dataset. This useful feature ensures that free space is available for an important dataset or log files. The general format of the
To clear any reservation:
The same principle applies to the This command shows any reservations or refreservations that exist on storage/home/bob:
21.4.10. CompressionZFS provides transparent compression. Compressing data written at the block level saves space and also increases disk throughput. If data compresses by 25% the compressed data writes to the disk at the same rate as the uncompressed version, resulting in an effective write speed of 125%. Compression can also be a great alternative to Deduplication because it does not require extra memory. ZFS offers different compression algorithms, each with different trade-offs. The introduction of LZ4 compression in ZFS v5000 enables compressing the entire pool without the large performance trade-off of other algorithms. The biggest advantage to LZ4 is the early abort feature. If LZ4 does not achieve at least 12.5% compression in the header part of the data, ZFS writes the block uncompressed to avoid wasting CPU cycles trying to compress data that is either already compressed or uncompressible. For details about the different compression algorithms available in ZFS, see the Compression entry in the terminology section. The administrator can see the effectiveness of compression using dataset properties.
The dataset is using 449 GB of space (the used property). Without compression, it would have taken 496 GB of space (the Compression can have an unexpected side effect when combined with User Quotas. User quotas restrict how much
actual space a user consumes on a dataset after compression. If a user has a quota of 10 GB, and writes 10 GB of compressible data, they will still be able to store more data. If they later update a file, say a database, with more or less compressible data, the amount of space available to them will change. This can result in the odd situation where a user did not increase the actual amount of data (the Compression can have a similar unexpected interaction with backups. Quotas are often used to limit data storage to ensure there is enough backup space available. Since quotas do not consider compression ZFS may write more data than would fit with uncompressed backups. 21.4.11. Zstandard CompressionOpenZFS 2.0 added a new compression algorithm. Zstandard (Zstd) offers higher compression ratios than the default LZ4 while offering much greater speeds than the alternative, gzip. OpenZFS 2.0 is available starting with FreeBSD 12.1-RELEASE via sysutils/openzfs and has been the default in since FreeBSD 13.0-RELEASE. Zstd provides a large selection of compression levels, providing fine-grained control over performance versus compression ratio. One of the main advantages of Zstd is that the decompression speed is independent of the compression level. For data written once but read often, Zstd allows the use of the highest compression levels without a read performance penalty. Even with frequent data updates, enabling compression often provides higher performance. One of the biggest advantages comes from the compressed ARC feature. ZFS’s Adaptive Replacement Cache (ARC) caches the compressed version of the data in RAM, decompressing it each time. This allows the same amount of RAM to store more data and metadata, increasing the cache hit ratio. ZFS offers 19 levels of Zstd compression, each offering incrementally more space savings in exchange for slower compression. The default level is If ZFS is not able to get the required memory to compress a block with Zstd, it will fall back to storing the block uncompressed. This is unlikely to happen except at the highest levels of
Zstd on memory constrained systems. ZFS counts how often this has occurred since loading the ZFS module with 21.4.12. DeduplicationWhen enabled, deduplication uses the checksum of each block to detect duplicate blocks. When a new block is a duplicate of an existing block, ZFS writes a new reference to the existing data instead of the whole duplicate block. Tremendous space savings are possible if the data contains a lot of duplicated files or repeated information. Warning: deduplication requires a large amount of memory, and enabling compression instead provides most of the space savings without the extra cost. To activate deduplication, set the Deduplicating only affects new data written to the pool. Merely activating this option will not deduplicate data already written to the pool. A pool with a freshly activated deduplication property will look like this example:
The
To observe deduplicating of redundant data, use:
The Deduplication is not always beneficial when the data in a pool is not redundant. ZFS can show potential space savings by simulating deduplication on an existing pool:
After 21.4.13. ZFS and JailsUse 21.5. Delegated AdministrationA comprehensive permission delegation system allows unprivileged users to perform ZFS administration functions. For example, if each user’s home directory is a dataset, users need permission to create and destroy snapshots of their home directories. A user performing backups can get permission to use replication features. ZFS allows a usage statistics script to run with access to only the space usage data for all users. Delegating the ability to delegate permissions is also possible. Permission delegation is possible for each subcommand and most properties. 21.5.1. Delegating Dataset Creation
21.5.2. Delegating Permission Delegation
21.6. Advanced Topics21.6.1. TuningAdjust tunables to make ZFS perform best for different workloads.
21.6.2. ZFS on i386Some of the features provided by ZFS are memory intensive, and may require tuning for upper efficiency on systems with limited RAM. 21.6.2.1. MemoryAs a lower value, the total system memory should be at least one gigabyte. The amount of recommended RAM depends upon the size of the pool and which features ZFS uses. A general rule of thumb is 1 GB of RAM for every 1 TB of storage. If using the deduplication feature, a general rule of thumb is 5 GB of RAM per TB of storage to deduplicate. While some users use ZFS with less RAM, systems under heavy load may panic due to memory exhaustion. ZFS may require further tuning for systems with less than the recommended RAM requirements. 21.6.2.2. Kernel ConfigurationDue to the address space limitations of the i386™ platform, ZFS users on the i386™ architecture must add this option to a custom kernel configuration file, rebuild the kernel, and reboot: This expands the kernel address space, allowing the 21.6.2.3. Loader TunablesIncreases the kmem address space on all FreeBSD architectures. A test system with 1 GB of physical memory benefitted from adding these options to /boot/loader.conf and then restarting: vm.kmem_size="330M" vm.kmem_size_max="330M" vfs.zfs.arc.max="40M" vfs.zfs.vdev.cache.size="5M" 21.7. Further Resources21.8. ZFS Features and TerminologyMore than a file system, ZFS is fundamentally different. ZFS combines the roles of file system and volume manager, enabling new storage devices to add to a live system and having the new space available on the existing file systems in that pool at once. By combining the traditionally separate roles, ZFS is able to overcome previous limitations that prevented RAID groups being able to grow. A vdev is a top level device in a pool and can be a simple disk or a RAID transformation such as a mirror or RAID-Z array. ZFS file systems (called datasets) each have access to the combined free space of the entire pool. Used blocks from the pool decrease the space available to each file system. This approach avoids the common pitfall with extensive partitioning where free space becomes fragmented across the partitions.
What is a ZFS pool?ZFS pool (Zpool) is a collection of one or more virtual devices, referred to as vdevs that appear as a single storage device accessible to the file system. The Zpool is the highest container in the whole ZFS system.
What file under the proc directory contains information regarding what modules are currently?/proc/mdstat: This file contains the current information for multiple-disk, RAID configurations. /proc/meminfo: This file reports a large amount of valuable information about the system's RAM usage. /proc/modules: This file displays a list of all modules loaded into the kernel.
What terms describe a computer connected to a remote hard disk via iSCSI and the remote hard disk?A computer connected to a remote hard disk via iSCSI is referred to as an iSCSI initiator.
Which are typically loaded into the Linux kernel as a module select three?But you can also add code to the Linux kernel while it is running. A chunk of code that you add in this way is called a loadable kernel module. These modules can do lots of things, but they typically are one of three things: 1) device drivers; 2) filesystem drivers; 3) system calls.
|