JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris ZFS Administration Guide     Oracle Solaris 11 Express 11/10
search filter icon
search icon

Document Information

Preface

1.  Oracle Solaris ZFS File System (Introduction)

What's New in ZFS?

ZFS File System Encryption

ZFS Send Stream Enhancements

ZFS Snapshot Differences (zfs diff)

ZFS Storage Pool Recovery and Performance Enhancements

Tuning ZFS Synchronous Behavior

Improved ZFS Pool Messages

ZFS ACL Interoperability Improvements

Splitting a Mirrored ZFS Storage Pool (zpool split)

Solaris iSCSI Changes

New ZFS System Process

ZFS Deduplication Property

Changes to the zpool list Command

ZFS Storage Pool Recovery

ZFS Log Device Enhancements

Triple Parity RAIDZ (raidz3)

Holding ZFS Snapshots

ZFS Device Replacement Enhancements

ZFS User and Group Quotas

ZFS ACL Pass Through Inheritance for Execute Permission

Automatic ZFS Snapshots

ZFS Property Enhancements

ZFS Log Device Recovery

Using ZFS ACL Sets

Using Cache Devices in Your ZFS Storage Pool

ZFS Root Pool Management

Rolling Back a Dataset Without Unmounting

Enhancements to the zfs send Command

ZFS Quotas and Reservations for File System Data Only

ZFS File System Properties for the Solaris CIFS Service

ZFS Storage Pool Properties

ZFS and File System Mirror Mounts

ZFS Command History Enhancements (zpool history)

Upgrading ZFS File Systems (zfs upgrade)

ZFS Delegated Administration

Setting Up Separate ZFS Log Devices

Creating Intermediate ZFS Datasets

ZFS Hot-Plugging Enhancements

Recursively Renaming ZFS Snapshots (zfs rename -r)

gzip Compression Is Available for ZFS

Storing Multiple Copies of ZFS User Data

Improved zpool status Output

ZFS and Solaris iSCSI Improvements

Sharing ZFS File System Enhancements

ZFS Command History (zpool history)

ZFS Property Improvements

ZFS xattr Property

ZFS canmount Property

ZFS User Properties

Setting Properties When Creating ZFS File Systems

Displaying All ZFS File System Information

New zfs receive -F Option

Recursive ZFS Snapshots

Double-Parity RAID-Z (raidz2)

Hot Spares for ZFS Storage Pool Devices

Replacing a ZFS File System With a ZFS Clone (zfs promote)

Upgrading ZFS Storage Pools (zpool upgrade)

Using ZFS to Clone Non-Global Zones and Other Enhancements

ZFS Backup and Restore Commands Are Renamed

Recovering Destroyed Storage Pools

ZFS Is Integrated With Fault Manager

The zpool clear Command

Compact NFSv4 ACL Format

File System Monitoring Tool (fsstat)

What Is ZFS?

ZFS Pooled Storage

Transactional Semantics

Checksums and Self-Healing Data

Unparalleled Scalability

ZFS Snapshots

Simplified Administration

ZFS Terminology

ZFS Component Naming Requirements

2.  Getting Started With Oracle Solaris ZFS

3.  Oracle Solaris ZFS and Traditional File System Differences

4.  Managing Oracle Solaris ZFS Storage Pools

5.  Managing ZFS Root Pool Components

6.  Managing Oracle Solaris ZFS File Systems

7.  Working With Oracle Solaris ZFS Snapshots and Clones

8.  Using ACLs and Attributes to Protect Oracle Solaris ZFS Files

9.  Oracle Solaris ZFS Delegated Administration

10.  Oracle Solaris ZFS Advanced Topics

11.  Oracle Solaris ZFS Troubleshooting and Pool Recovery

A.  Oracle Solaris ZFS Version Descriptions

Index

What Is ZFS?

The Solaris ZFS file system is a revolutionary new file system that fundamentally changes the way file systems are administered, with features and benefits not found in any other file system available today. ZFS is robust, scalable, and easy to administer.

ZFS Pooled Storage

ZFS uses the concept of storage pools to manage physical storage. Historically, file systems were constructed on top of a single physical device. To address multiple devices and provide for data redundancy, the concept of a volume manager was introduced to provide a representation of a single device so that file systems would not need to be modified to take advantage of multiple devices. This design added another layer of complexity and ultimately prevented certain file system advances because the file system had no control over the physical placement of data on the virtualized volumes.

ZFS eliminates volume management altogether. Instead of forcing you to create virtualized volumes, ZFS aggregates devices into a storage pool. The storage pool describes the physical characteristics of the storage (device layout, data redundancy, and so on) and acts as an arbitrary data store from which file systems can be created. File systems are no longer constrained to individual devices, allowing them to share disk space with all file systems in the pool. You no longer need to predetermine the size of a file system, as file systems grow automatically within the disk space allocated to the storage pool. When new storage is added, all file systems within the pool can immediately use the additional disk space without additional work. In many ways, the storage pool works similarly to a virtual memory system: When a memory DIMM is added to a system, the operating system doesn't force you to run commands to configure the memory and assign it to individual processes. All processes on the system automatically use the additional memory.

Transactional Semantics

ZFS is a transactional file system, which means that the file system state is always consistent on disk. Traditional file systems overwrite data in place, which means that if the system loses power, for example, between the time a data block is allocated and when it is linked into a directory, the file system will be left in an inconsistent state. Historically, this problem was solved through the use of the fsck command. This command was responsible for reviewing and verifying the file system state, and attempting to repair any inconsistencies during the process. This problem of inconsistent file systems caused great pain to administrators, and the fsck command was never guaranteed to fix all possible problems. More recently, file systems have introduced the concept of journaling. The journaling process records actions in a separate journal, which can then be replayed safely if a system crash occurs. This process introduces unnecessary overhead because the data needs to be written twice, often resulting in a new set of problems, such as when the journal cannot be replayed properly.

With a transactional file system, data is managed using copy on write semantics. Data is never overwritten, and any sequence of operations is either entirely committed or entirely ignored. Thus, the file system can never be corrupted through accidental loss of power or a system crash. Although the most recently written pieces of data might be lost, the file system itself will always be consistent. In addition, synchronous data (written using the O_DSYNC flag) is always guaranteed to be written before returning, so it is never lost.

Checksums and Self-Healing Data

With ZFS, all data and metadata is verified using a user-selectable checksum algorithm. Traditional file systems that do provide checksum verification have performed it on a per-block basis, out of necessity due to the volume management layer and traditional file system design. The traditional design means that certain failures, such as writing a complete block to an incorrect location, can result in data that is incorrect but has no checksum errors. ZFS checksums are stored in a way such that these failures are detected and can be recovered from gracefully. All checksum verification and data recovery are performed at the file system layer, and are transparent to applications.

In addition, ZFS provides for self-healing data. ZFS supports storage pools with varying levels of data redundancy. When a bad data block is detected, ZFS fetches the correct data from another redundant copy and repairs the bad data, replacing it with the correct data.

Unparalleled Scalability

A key design element of the ZFS file system is scalability. The file system itself is 128 bit, allowing for 256 quadrillion zettabytes of storage. All metadata is allocated dynamically, so no need exists to preallocate inodes or otherwise limit the scalability of the file system when it is first created. All the algorithms have been written with scalability in mind. Directories can have up to 248 (256 trillion) entries, and no limit exists on the number of file systems or the number of files that can be contained within a file system.

ZFS Snapshots

A snapshot is a read-only copy of a file system or volume. Snapshots can be created quickly and easily. Initially, snapshots consume no additional disk space within the pool.

As data within the active dataset changes, the snapshot consumes disk space by continuing to reference the old data. As a result, the snapshot prevents the data from being freed back to the pool.

Simplified Administration

Most importantly, ZFS provides a greatly simplified administration model. Through the use of a hierarchical file system layout, property inheritance, and automatic management of mount points and NFS share semantics, ZFS makes it easy to create and manage file systems without requiring multiple commands or the editing configuration files. You can easily set quotas or reservations, turn compression on or off, or manage mount points for numerous file systems with a single command. You can examine or replace devices without learning a separate set of volume manager commands. You can send and receive file system snapshot streams.

ZFS manages file systems through a hierarchy that allows for this simplified management of properties such as quotas, reservations, compression, and mount points. In this model, file systems are the central point of control. File systems themselves are very cheap (equivalent to creating a new directory), so you are encouraged to create a file system for each user, project, workspace, and so on. This design enables you to define fine-grained management points.