Managing ZFS File System Changes

ZFS file system encryption – You can encrypt a ZFS file system when it is created. For more information, see Chapter 9, Managing Security.
ZFS file system deduplication – For important information about determining whether your system environment can support ZFS data deduplication, see ZFS Data Deduplication Requirements.
ZFS file system sharing – Includes both NFS and SMB file system sharing changes. For more information, seeZFS File System Sharing Changes.
ZFS man page change – The zfs.1m manual page has been revised so that core ZFS file system features remain in the zfs.1m page, but delegated administration, encryption, and share syntax and examples are covered in the following pages:

Displaying ZFS File System Information

After the system is installed, review your ZFS storage pool and ZFS file system information.

Display ZFS storage pool information by using the zpool status command. For example:

# zpool status
 pool: rpool
 state: ONLINE
 scan: none requested
config:
 NAME STATE READ WRITE CKSUM
 rpool ONLINE 0 0 0
 c2t0d0s0 ONLINE 0 0 0
errors: No known data errors

Display ZFS file system information by using the zfs list command. For example:

# zfs list -r rpool
NAME USED AVAIL REFER MOUNTPOINT
NAME USED AVAIL REFER MOUNTPOINT
rpool 5.39G 67.5G 74.5K /rpool
rpool/ROOT 3.35G 67.5G 31K legacy
rpool/ROOT/solaris 3.35G 67.5G 3.06G /
rpool/ROOT/solaris/var 283M 67.5G 214M /var
rpool/dump 1.01G 67.5G 1000M -
rpool/export 97.5K 67.5G 32K /rpool/export
rpool/export/home 65.5K 67.5G 32K /rpool/export/home
rpool/export/home/admin 33.5K 67.5G 33.5K /rpool/export/home/admin
rpool/swap 1.03G 67.5G 1.00G -

For a description of the root pool components, see Reviewing the Initial ZFS BE After an Installation.

Resolving ZFS File System Space Reporting Issues

The zpool list and zfs list commands are better than the previous df and du commands for determining your available pool and file system space. With the legacy commands, you cannot easily discern between pool and file system space, nor do the legacy commands account for space that is consumed by descendent file systems or snapshots.

For example, the following root pool (rpool) has 5.46 GB allocated and 68.5 GB free.

# zpool list rpool
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
rpool 74G 5.46G 68.5G 7% 1.00x ONLINE -

If you compare the pool space accounting with the file system space accounting by reviewing the USED columns of your individual file systems, you can see that the pool space is accounted for. For example:

# zfs list -r rpool
NAME USED AVAIL REFER MOUNTPOINT
rpool 5.41G 67.4G 74.5K /rpool
rpool/ROOT 3.37G 67.4G 31K legacy
rpool/ROOT/solaris 3.37G 67.4G 3.07G /
rpool/ROOT/solaris/var 302M 67.4G 214M /var
rpool/dump 1.01G 67.5G 1000M -
rpool/export 97.5K 67.4G 32K /rpool/export
rpool/export/home 65.5K 67.4G 32K /rpool/export/home
rpool/export/home/admin 33.5K 67.4G 33.5K /rpool/export/home/admin
rpool/swap 1.03G 67.5G 1.00G -

Resolving ZFS Storage Pool Space Reporting Issues

The SIZE value that is reported by the zpool list command is generally the amount of physical disk space in the pool, but varies depending on the pool's redundancy level. See the examples below. The zfs list command lists the usable space that is available to file systems, which is disk space minus ZFS pool redundancy metadata overhead, if any.

Non-redundant storage pool – Created with one 136-GB disk, the zpool list command reports SIZE and initial FREE values as 136 GB. The initial AVAIL space reported by the zfs list command is 134 GB, due to a small amount of pool metadata overhead. For example:
```
# zpool create tank c0t6d0
# zpool list tank
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 136G 95.5K 136G 0% 1.00x ONLINE -
# zfs list tank
NAME USED AVAIL REFER MOUNTPOINT
tank 72K 134G 21K /tank
```
Mirrored storage pool– Created with two 136-GB disks, zpool list command reports SIZE as 136 GB and initial FREE value as 136 GB. This reporting is referred to as the deflated space value. The initial AVAIL space reported by the zfs list command is 134 GB, due to a small amount of pool metadata overhead. For example:
```
# zpool create tank mirror c0t6d0 c0t7d0 
# zpool list tank
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 136G 95.5K 136G 0% 1.00x ONLINE -
# zfs list tank
NAME USED AVAIL REFER MOUNTPOINT
tank 72K 134G 21K /tank
```
RAID-Z storage pool – Created with three 136-GB disks, the zpool list commands reports SIZE as 408 GB and initial FREE value as 408 GB. This reporting is referred to as the inflated disk space value, which includes redundancy overhead, such as parity information. The initial AVAIL space reported by the zfs list command is 133 GB, due to the pool redundancy overhead. The following example creates a RAIDZ-2 pool.
```
# zpool create tank raidz2 c0t6d0 c0t7d0 c0t8d0
# zpool list tank
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
tank 408G 286K 408G 0% 1.00x ONLINE -
# zfs list tank
NAME USED AVAIL REFER MOUNTPOINT
tank 73.2K 133G 20.9K /tank
```

Making ZFS File Systems Available

Making ZFS file systems available is similar to Oracle Solaris 10 releases in the following ways:

A ZFS file system is mounted automatically when it is created and then remounted automatically when the system is booted.
You do not have to modify the /etc/vfstab file to mount a ZFS file system, unless you create a legacy mount for ZFS file system. Mounting a ZFS file system automatically is recommended over using a legacy mount.
You do not have to modify the /etc/dfs/dfstab file to share file systems. For more information about sharing ZFS file systems, see ZFS File System Sharing Changes.
Similar to a UFS root, the swap device must have an entry in the /etc/vfstab file.
File systems can be shared between Oracle Solaris 10 and Oracle Solaris 11 systems by using NFS sharing.
File systems can be shared between Oracle Solaris 11 systems by using NFS or SMB sharing.
ZFS storage pools can be exported from an Oracle Solaris 10 system and then imported on an Oracle Solaris 11 system.

ZFS File System Sharing Changes

In Oracle Solaris 10, you could set the sharenfs or sharesmb property to create and publish a ZFS file system share, or you could use the legacy share command.

In this Solaris release, you create a ZFS file system share and then publish the share as follows:

Create an NFS or SMB share of a ZFS file system by using the zfs set share command. For example:

# zfs create rpool/fs1
# zfs set share=name=fs1,path=/rpool/fs1,prot=nfs rpool/fs1
name=fs1,path=/rpool/fs1,prot=nfs

Publish the NFS or SMB share by setting the sharenfs or sharesmb property to on. For example:

# zfs set sharenfs=on rpool/fs1
# cat /etc/dfs/sharetab
/rpool/fs1 fs1 nfs sec=sys,rw

The primary new sharing differences are as follows:

The zfs set share command replaces the sharemgr interface for sharing ZFS file systems.
The sharemgr interface is no longer available. The legacy share command and the sharenfs property are still available. See the examples below.
The /etc/dfs/dfstab file still exists but modifications are ignored. SMF manages ZFS or UFS share information so that file systems are shared automatically when the system is rebooted, similar to the way ZFS mount and share information is managed.
File system shares that are shared by using the share -a command are persistent.
Descendent file systems do not inherit share properties. If a descendent file system is created with an inherited sharenfs property set to on, then a share is created for the new descendent file system.

Legacy ZFS Sharing Syntax

Legacy sharing syntax is still supported without having to modify the /etc/dfs/dfstab file. Legacy shares are managed by an SMF service.

Use the share command to share a file system.

For example, to share a ZFS file system:

# share -F nfs /tank/zfsfs
# cat /etc/dfs/sharetab
/tank/zfsfs - nfs rw

The above syntax is identical to sharing a UFS file system:

# share -F nfs /ufsfs
# cat /etc/dfs/sharetab
/ufsfs - nfs rw 
/tank/zfsfs - nfs rw

You can create a file system with the sharenfs property enabled, as in previous releases. The Oracle Solaris 11 behavior is that a default share is created for the file system.
```
# zfs create -o sharenfs=on rpool/data
# cat /etc/dfs/sharetab
/rpool/data rpool_data nfs sec=sys,rw
```

The above file system shares are published immediately.

ZFS Sharing Migration/Transition Issues

Review the share transition issues in this section.

Upgrading your system – ZFS shares will be incorrect if you boot back to an older BE due to property changes in this release. Non-ZFS shares are unaffected. If you plan to boot back to an older BE, save a copy of the existing share configuration prior to the pkg update operation to be able to restore the share configuration on the ZFS datasets.
- In the older BE, use the sharemgr show -vp command to list all shares and their configuration.
- Use the zfs get sharenfs filesystem command and the zfs sharesmb filesystem commands to get the values of the sharing properties.
- If you boot back to an older BE, reset the sharenfs and sharesmb properties to their original values.
Legacy unsharing behavior – Using the unshare -a command or unshareall command unpublishes a share, but does not update the SMF shares repository. If you try to re-share the existing share, the shares repository is checked for conflicts, and an error is displayed.

ZFS Data Deduplication Requirements

In Oracle Solaris 11, you can use the deduplication (dedup) property to remove redundant data from your ZFS file systems. If a file system has the dedup property enabled, duplicate data blocks are removed synchronously. The result is that only unique data is stored, and common components are shared between files. For example:

# zfs set dedup=on tank/home

Do not enable the dedup property on file systems that reside on production systems until you perform the following steps to determine if your system can support data deduplication.

Determine if your data would benefit from deduplication space savings. If your data is not dedup-able, there is no point in enabling dedup. Running the following command is very memory intensive:

# zdb -S tank
Simulated DDT histogram:
bucket allocated referenced 
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
 1 2.27M 239G 188G 194G 2.27M 239G 188G 194G
 2 327K 34.3G 27.8G 28.1G 698K 73.3G 59.2G 59.9G
 4 30.1K 2.91G 2.10G 2.11G 152K 14.9G 10.6G 10.6G
 8 7.73K 691M 529M 529M 74.5K 6.25G 4.79G 4.80G
 16 673 43.7M 25.8M 25.9M 13.1K 822M 492M 494M
 32 197 12.3M 7.02M 7.03M 7.66K 480M 269M 270M
 64 47 1.27M 626K 626K 3.86K 103M 51.2M 51.2M
 128 22 908K 250K 251K 3.71K 150M 40.3M 40.3M
 256 7 302K 48K 53.7K 2.27K 88.6M 17.3M 19.5M
 512 4 131K 7.50K 7.75K 2.74K 102M 5.62M 5.79M
 2K 1 2K 2K 2K 3.23K 6.47M 6.47M 6.47M
 8K 1 128K 5K 5K 13.9K 1.74G 69.5M 69.5M
 Total 2.63M 277G 218G 225G 3.22M 337G 263G 270G
dedup = 1.20, compress = 1.28, copies = 1.03, dedup * compress / copies = 1.50

If the estimated dedup ratio is greater than 2, then you might see dedup space savings.

In this example, the dedup ratio (dedup = 1.20) is less than 2, so enabling dedup is not recommended.

Make sure your system has enough memory to support dedup.
- Each in-core dedup table entry is approximately 320 bytes.
- Multiply the number of allocated blocks times 320. For example:
```
in-core DDT size = 2.63M x 320 = 841.60M
```
Dedup performance is best when the deduplication table fits into memory. If the dedup table has to be written to disk, then performance will decrease. If you enable deduplication on your file systems without sufficient memory resources, system performance might degrade during file system related operations. For example, removing a large dedup-enabled file system without sufficient memory resources might impact system performance. .

Previous Next