Go to main content

Managing ZFS File Systems in Oracle® Solaris 11.4

Exit Print View

Updated: July 2019
 
 

Planning the ZFS Implementation

This section describes factors you need to consider before configuring ZFS.

Naming ZFS Components

Each ZFS component, such as datasets and pools, must be named according to the following rules:

  • Each component can contain only alphanumeric characters in addition to the following special characters:

    • Underscore (_)

    • Hyphen (-)

    • Colon (:)

    • Period (.)

    • Blank (" ")


      Note -  Tabs and other white spaces are not valid.
  • Pool names must begin with a letter and can contain only alphanumeric characters as well as underscore (_), dash (-), and period (.). Note the following pool name restrictions:

    • The beginning sequence c[0-9] is not allowed.

    • The name log is reserved.

    • A name that begins with mirror, raidz, raidz1, raidz2, raidz3, or spare is not allowed because these names are reserved.

    • Pool names must not contain a percent sign (%).

  • Dataset names must begin with an alphanumeric character.

  • Dataset names must not contain a percent sign (%).

  • Empty components are not allowed.

Identifying Storage Requirements

The pool describes the physical characteristics of the storage. You must be create the pool before any file systems.

Before creating a storage pool, determine which devices will store your data. These devices must be disks of at least 128 MB in size, and they must not be in use by other parts of the operating system. Allocate entire disks to ZFS rather than individual slices on a preformatted disk.

For more information about disks and how they are used and labeled, see Using Disks in a ZFS Storage Pool.

Choosing the Type of Data Redundancy

ZFS supports multiple types of data redundancy, which determines the types of hardware failures the pool can withstand. ZFS supports nonredundant (striped) configurations, as well as mirroring and RAID-Z, which is a variation on RAID-5.

For more information about ZFS redundancy features, see Redundancy Features of a ZFS Storage Pool.

Determining the ZFS File System Hierarchy

File system hierarchies are created on pools.

Hierarchies are simple, easy to understand, yet powerful mechanisms for organizing information. This section describes specific issues regarding hierarchy planning.

Selecting the File System Granularity

ZFS supports file systems organized into hierarchies, where each file system has only a single parent. The root of the hierarchy is always the pool name. ZFS supports property inheritance so that common you can set properties quickly and easily on entire trees of file systems by using hierarchies.

ZFS file systems provide a central point of administration. They are lightweight enough that you can establish one file system per user or project. This model enables you to control properties, snapshots, and backups on a per-user or per-project basis.

For more information about managing file systems, see Managing Oracle Solaris ZFS File Systems.

Grouping File Systems

You can group similar ZFS file systems into hierarchies under a common name. The hierarchy becomes the central point for administering and controlling file systems and their properties.

In Example 1, Configuring a Mirrored ZFS File System, the two file systems are placed under a file system named home.

Choosing File System Properties

You determine most file system characteristics properties. These properties control a variety of behaviors, including where the file systems are mounted, how they are shared, whether they use compression, or whether any quotas are in effect.

For more information about properties, see Introducing ZFS Properties.