Getting Started

This chapter provides step-by-step instructions for setting up simple ZFS configurations. By the end of this chapter, you should have a basic idea of how the ZFS commands work, and should be able to create simple pools and filesystems. It is not designed to be a comprehensive overview, and refers to later chapters for more detailed information.

The following sections are provided in this chapter.

• 2.1 Hardware and Software Requirements

• 2.2 Creating a Basic Filesystem

• 2.3 Creating a Storage Pool

• 2.4 Creating a Filesystem Hierarchy

2.1 Hardware and Software Requirements

Make sure the following hardware and software requirements are met before attempting to use the ZFS software.

• A SPARC or x86 system that is running the Solaris Nevada release, build 27.

• The minimum disk size is 128 Mbytes. The minimum amount of disk space required for a storage pool is 64 Mbytes.

• A minimum of 128 Mbytes of memory.

If you create a mirrored disk configuration, multiple controllers are recommended.

2.2 Creating a Basic Filesystem

ZFS administration has been designed with simplicity in mind. Among the goals of the commands is to reduce the number of commands needed to create a usable filesystem. Assuming that the whole disk /dev/dsk/c0t0d0 is available for use, the following sequence of commands will create a filesystem for you to use:

# zpool create tank c0t0d0
# zfs create tank/fs

This creates a new storage pool with the name tank, and a single filesystem in that pool with the name fs. This new filesystem can use as much of the disk space on c0t0d0 as needed, and is automatically mounted at /tank/fs:

# mkfile 100m /tank/fs/foo
# df -h /tank/fs
Filesystem             size   used  avail capacity  Mounted on
tank/fs                 80G   100M    80G     1%    /tank/fs

2.3 Creating a Storage Pool

While the previous example serves to illustrate the simplicity of ZFS, it is not a terribly useful example. In the remainder of this chapter, we will demonstrate a more complete example similar to what we would encounter in a real world environment. The first step is to create a storage pool. The pool describes the physical characteristics of the storage and must be created before any filesystems.

Identifying Storage Requirements

Steps

1. Determine available devices.

   Before creating a storage pool, you must determine which devices will store your data. These must be disks of at least 128 Mbytes in size, and must not be in use by other parts of the operating system. The devices can be individual slices on a pre-formatted disk, or they can be entire disks which ZFS will format to be a single large slice. For this example, we will assume that the whole disks /dev/dsk/c0t0d0 and /dev/dsk/c0t0d1 are available for use.

   For more information on devices and how they are used and labelled, see 4.1.1 Disks.

2. Choose data replication.

   ZFS supports multiple types of data replication, which determines what types of hardware failures the pool is able to withstand. ZFS supports non-redundant (striped) configurations, as well mirroring and RAID-Z (a variation on RAID-5). For this example, we will use basic mirroring between the two available disks.

Creating the Pool

Steps

1. Become root or assume an equivalent role with the appropriate ZFS rights profile.

   For more information about the ZFS rights profiles, see 8.4 ZFS Rights Profiles.

2. Pick a pool name.

   The name is used to identify this storage pool when using any of the zpool(1M) or zfs(1M) commands. Most systems will require only a single pool, so you can pick any name that your prefer, provided it satisfies the naming requirements outlined in 1.3 ZFS Component Naming Conventions. For this example, we will use the pool name tank.

3. Create the pool.

   Execute the following command to create the pool:

   # zpool create tank mirror c0t0d0 c0t0d1

   
   

   If one or more of the devices contains another filesystem or is otherwise in use, the command will refuse to create the pool.

   For more information on creating storage pools, see 4.4.1 Creating a Pool.

   For more information on how devices usage is determined, see 4.4.2.1 Detecting In-Use Devices.

4. Viewing the result.

   You can see that your pool was successfully created by using the zpool list command:

   # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 80G 137K 80G 0% ONLINE -

   
   

   For more information on getting pool status, see 4.6 Querying Pool Status.

2.4 Creating a Filesystem Hierarchy

Now that you have created a storage pool to hold your data, you can create your filesystem hierarchy. Name hierarchies are a simple yet powerful mechanism for organizing information. They are also very familiar to anyone who has used a filesystem.

ZFS allows filesystems to be organized into arbitrary hierarchies, where each filesystem has only a single parent. The root of the name hierarchy is always the pool name. ZFS leverages this hierarchy by supporting property inheritance, so that common properties can be set quickly and easily on entire trees of filesystems.

Determining Filesystem Hierarchy

Steps

1. Pick filesystem granularity.

   ZFS filesystems are the central point of administration. They are lightweight, and can be created easily. A good model to use is a filesystem per user or project, as this allows properties, snapshots, and backups to be controlled on a per-user or per-project basis. For this example, we will be creating a filesystem for each of two users: bonwick and billm

   For more information on managing filesystems, see Chapter 5, Managing Filesystems.

2. Group similar filesystems together.

   ZFS allows filesystems to be organized into hierarchies so that similar filesystems can be grouped together. This provides a central point of administration for controlling properties and administering filesystems. Similar filesystems should be created under a common name. For this example, we will place our two filesystems under a filesystem named home.

3. Choosing filesystem properties.

   Most filesystem characteristics are controlled using simple properties. These properties control a variety of behavior, including where the filesystems are mounted, how they are shared, whether they use compression, and if there are any quotas in effect. For this example, we want all home directories to be mounted at /export/home/user, shared via NFS, and with compression. In addition, we will enforce a quota of 10 Gbytes on bonwick.

   For more information on properties, see 5.2 ZFS Properties.