Solaris Zfs Lab PDF
Solaris Zfs Lab PDF
1 Introduction
Oracle Solaris ZFS is a revolutionary file system that changes the way we manage
storage. Participants in this lab will gain awareness through example of devices,
storage pools, and performance and availability. We will learn about the various
types of ZFS datasets and when to use each type. We will examine snapshots,
cloning, allocation limits, and recovering from common errors.
- Zpools
- Vdevs
- ZFS datasets
- Snapshots / Clones
- ZFS properties
- ZFS updates
These exercises are meant to provide a primer into the value and flexibility of Oracle
Solaris 11 ZFS for the enterprise. Upon completion of this lab, the learner will
understand the simplicity and power of the ZFS file system and how it can help
address business requirements with Oracle Solaris 11 storage technology and will
be well on their way to mastering this powerful technology.
2 Overview
ZFS is the default file system in Oracle Solaris 11. This lab will follow the basic
system administration duties revolving around storage in a basic system. As in any
installation or implementation we’ll follow a basic path for building our storage
infrastructure
3 Pre-requisites
This lab requires the use of the following elements:
A current laptop with at least 3GB memory and 100GB free disk space
Oracle VirtualBox Software (4.0.16 with Extension Pack installed)
Oracle Solaris 11 11/11 PreBuilt VM for Oracle VM VirtualBox
The following assumptions have been made regarding the environment where this
lab is being performed:
4 Lab Setup
4.1 Oracle VirtualBox Hypervisor Software basics
Your system should already have Oracle VirtualBox hypervisor software installed
and ready to use. For this lab we will require a GUI interface and will be using the
pre-built Oracle Solaris 11 VM image. We only need to acquire it and import it to
get running quickly.
Make sure that you have the Oracle Solaris 11 VM Image copied to your
laptop hard disk.
Unzip the Solaris 11 image to your hard disk
In the VirtualBox Manager Screen click ‘New’
Click Next on the welcome screen
en to the left.
In this lab we are utilizing a pre-built Oracle Solaris Image. This image is based on
the desktop version and we will be running in the Gnome environment. Even
though the system has been pre-installed, we still have to answer the basic
installation questions in order to get things running for the ZFS lab. The system will
run through the basic set up dialog as illustrated below.
Username: labuser
It’s easier to work as root during the labs, remember to su - to root when first
logging in because root is a role and not a user. Let’s ‘su’ to root, confirm our
environment, and create some disk files before we get started with ZFS.
‘su –‘ to root,
to confirm that our 4 SAS disks are available to the system. cd to the /dev/dsk
directory and create 4 disk files using the mkfile command.
That's all there is to it. We can use zpool status to see what our first pool looks like.
Note from this output that the pool names datapool has a single ZFS virtual device
(vdev) called raidz1-0. That vdev is comprised of our four disk files that we created
in the previous step.
The RAIDZ1-0 type vdev provides single device parity protection, meaning that if
one device develops an error, no data is lost because it can be reconstructed using
the remaining disk devices. This organization is commonly called a 3+1, 3 data disks
plus one parity.
Before continuing, let's take a look at the currently mounted file systems.
# zfs list
One thing to notice in the ZFS makes things easier category is that when we created
the ZFS pool with one simple command, ZFS also created the first file system and
also mounted it. The default mountpoint is derived from the name of the pool but
can be changed easily.
Note:
Things we no longer have to do with ZFS are …
Create a filesystem
Make a directory to mount the filesystem
Add entries to /etc/vfstab
We’ve decided that we need a different type of vdev for our datapool example. Let’s
destroy this pool and create another.
All file systems in the pool have been unmounted and the pool has been destroyed.
The devices in the vdev have also been marked as free so they can be used again.
Notice how easy it is to destroy and there’s no ‘destroy? Are you sure?’ warning.
Next, let’s create a simple pool using a 2 way mirror instead of raidz.
Now the vdev name has changed to mirror-0 to indicate that data redundancy is
provided by mirroring (redundant copies of the data).
What happens if you try to use a disk device that is already being used by another
pool?
The usage error indicates that /dev/dsk/disk1 has been identified as being part of an
existing pool called datapool. The -f flag to the zpool create command can override
the failsafe in case datapool is no longer being used, but use that option with
caution.
Our application has made it necessary to add more space the the ‘datapool’. The
next exercise will show you how simple it is to add capacity to an existing pool.
Note that a second vdev (mirror-1) has been added to the pool.
To see if your pool has actually grown, do another # zfs list command.
# zfs list datapool
Notice that you don't have to grow file systems when the pool capacity increases.
File systems can use whatever space is available in the pool, subject to quota
limitations, which we will examine in a later exercise.
ZFS zpools can also be exported, allowing all of the data and associated
configuration information to be moved from one system to another. For this
example, use the two SAS disks (c4t0d0 and c4t1d0).
As before, we have created a simple mirrored pool of two disks. In this case, the disk
devices are real disks, not files. We've told ZFS to use the entire disk (no slice
number was included) and if the disk was not labeled, ZFS will write a default label.
ZFS Storage pools can be exported in order to migrate them easily to other system.
Storage pools should be explicitly exported to indicate that they are ready to be
migrated. This operation flushes any unwritten data to disk, writes data to the disk
indicating that the export was done, and removes all knowledge of the pool from the
system.
# zpool list
Note that our pool, ‘pool2’ is no longer in our list of available pools.
The next step will be to import the pool, again showing how easy ZFS is to use.
# zpool list
Notice that we didn't have to tell ZFS where the disks were located. All we told ZFS
was the name of the pool. ZFS looked through all of the available disk devices and
reassembled the pool, even if the device names had been changed.
If you don’t know the name of the pool ZFS will provide the names of available
Without an argument, ZFS will look at all of the disks attached to the system and will
provide a list of pool names that it can import. If it finds two pools of the same name,
the unique identifier can be used to select which pool you want imported.
There are many pool properties that can be customized for your environment. To
see a list of these properties type the following command.
Pool properties are described in the zpool(1M) man page. Pool properties provide
information about the pool, effect performance, security, and availability. To set a
pool property, use zpool set. Note that not all properties can be changed (ex.
version, free, allocated).
Set the ‘listsnapshot’ property to ‘on’. The listsnapshot (also listsnaps) controls
whether information about snapshots is displayed when the ‘zfs list’ command is
run without the –t option. The default value is ‘off’.
As with any software package, ZFS goes through upgrades over time. Let’s take a
look at how we can find the zpool version number, features provided by that
version, and how we can potentially upgrade, or even downgrade our ZFS Pool
version to accommodate potential compatibility scenarios. To find out what
features have been added over time, use the below command.
# zpool upgrade -v
When you patch or upgrade Oracle Solaris, a new version of zpool may be available.
It is simple to upgrade or downgrade an existing pool. We’ll create a pool using an
older version number, and then upgrade the pool.
The next step would be to upgrade the old pool to the latest version. Execute the
It’s that simple. Now you can use features provided in the newer zpool version, like
log device removal (19), snapshot user holds (18), etc.
This concludes the section on pools. There is a wealth of features that we haven’t
explored yet. Check out the man page for many other features that you can take
advantage of.
A mirrored ZFS storage pool can be quickly cloned as a backup pool by using the
zpool split command.
First let’s create a mirrored ZFS pool named pool3 with two of our SAS disks.
Remember that our pool is automatically mounted so let’s go ahead and create some
data and store it in the resulting file system.
First let’s check the status of the file system for size and then let’s split the pool and
create our instant backup copy. We will provide a name for the resulting second
pool and call it ‘pool4’.
Note that our pool now only contains a single disk but the size is still the same. And
running the ls command shows that our file is still there and has not come to any
harm.
Our new pool doesn’t show up in the list because it still needs to be imported. Let’s
do that now.
That confirms our split pools. Now let’s verify that our file has been duplicated in
the filesystem.
# ls –l /pool3
# ls –l /pool4
Now just for the heck of it, let’s put the mirror back together. If this were a
production system you would ensure that complete and proper backups were done
before playing with splits and joins like this in a filesystem no matter how
trustworthy the software may be.
First we’ll need to destroy pool4 because it has the disk we want to put back into the
mirror. Then we’ll use the attach subcommand to bring a new disk into our
nonredundant single disk pool as a mirror. With the attach command you need to
list the existing device first and then the device you wish to join into the mirror.
The mirrored pool is now back to normal and the file it contained is still intact.
# ls –l /pool3
ZFS datasets are created, destroyed and managed using the zfs(1M) command.
To begin working with datasets, let's create a simple pool, again called datapool and
4 additional datasets called bob joe fred and pat. Execute the following commands
on your system…
By using zfs list -r datapool, we are listing all of the datasets in the pool
named datapool. As in the earlier exercise, all of these datasets (file systems) have
been automatically mounted.
If this was a traditional file system, you might think there was 19.55 GB (3.81 GB x
5) available for datapool and its 4 datasets, but the 4GB in the pool is shared across
all of the datasets. To see an example of this behavior, type the following
commands:
Notice that in the USED column, datapool/bob shows 1GB in use. The other datasets
show just the metadata overhead (31k), but their available space has been reduced
to 2.95GB, the amount of free space available to them after the consumption of 1GB
by the datapool/bob dataset.
A dataset can have children, just as a directory can have subdirectories. For
datapool/fred, let's create a dataset for documents, and then underneath that,
additional datasets for pictures, video and audio. Execute the following commands:
ZFS datasets are flexible and can be manipulated with a myriad of properties. The
next short exercise will examine some ZFS dataset properties and how to
manipulate them and why.
ZFS dataset quotas are used to limit the amount of space consumed by a dataset
and all of its children. Reservations are used to guarantee that a dataset has an
allocated amount of storage that can’t be consumed by other datasets in use.
The first thing to notice is that the available space for datapool/fred and all of its
children is now 2GB, which was the quota we set with the command above. Also
notice that the quota is inherited by all of the children.
With a traditional UNIX file systems changing a mountpoint would require a few
steps, including …
With ZFS it can be done with a single command. In the next example, let's move
datapool/fred to a directory just called /fred. First let’s look at the current
mountpoint.
Notice that not only did the command change datapool/fred, but also all of its
Let’s look at another type of dataset, the zvol and what it can do.
Volumes, or zvols, provide a block level (raw and cooked) interface into the zpool.
Instead of creating a file system where you place files and directories, a single object
is created and then accessed as if it were a real disk device. This would be used for
things like raw database files, virtual machine disk images and legacy file systems.
Oracle Solaris also uses this for the swap and dump devices when installed into a
zpool.
In this example, rpool/dump is the dump device for Solaris and it 516MB.
rpool/swap is the swap device and it is 1GB. As you can see, you can mix files and
devices within the same pool.
Unlike a file system dataset, you must specifically designate the size of the device
when you create it, but you can change it later if needed. It's just another dataset
property. Create a volume.
# newfs /dev/zvol/rdsk/datapool/vol1
Expanding a volume is just a matter of setting the dataset property volsize to a new
value. Be careful when lowering the value as this will truncate the volume and you
could lose data. In this next example, let's grow our volume from 500MB to 1GB.
Since there is a UFS file system on it, we'll use growfs to make the file system use the
new space.
ZFS provides the ability to preserve the contents of a dataset through the use of
snapshots. And snapshots are easy to create and take up virtually no space when
they’re first created. Type the below commands to create some snapshots.
The value after the @ denotes the name of the snapshot. Any number of snapshots
can be taken.
Delete these snapshots as they won’t be needed for the actual lab.
We can use our point in time snapshots to create new datasets called clones Clones
are datasets, just like any other, but start off with the contents from the snapshot.
Clones and snapshots make efficient use of storage. Clones only require space for
the data that's different than the snapshot. That means that if 5 clones are created
from a single snapshot, only 1 copy of the common data is required.
Remember that datapool/bob has a 1GB file in it? Let's take a snapshot of the
datapool and then create some clones.
We can see that there's a 1GB file in datapool/bob. Right now, that's the dataset
being charged with the copy, although all of the clones can use it.
Now let's delete it in the original file system, and all of the clones, and see what
happens.
# rm /datapool/*/bigfile
# zfs list –r –o space datapool
Notice that the 1GB has not been freed (avail space is still 382M), but the USEDSNAP
value for datapool/bob has gone from 0 to 1GB, indicating that the snapshot is
The 1GB file that we deleted has been freed because the last snapshot holding it has
been deleted.
You can also take a snapshot of a dataset and all of its children. A recursive
snapshot is atomic, meaning that it is a consistent point in time picture of the
contents of all of the datasets. Use -r for a recursive snapshot.
The last item we’ll cover is a new command in Oracle Solaris 11, the ZFS diff
command. The diff command enables a system administrator to determine the
differences between different ZFS snapshots.
Let’s start by creating some snapshots and adding files to a user’s home directory.
Assuming you have the ‘labuser’ in your Solaris instance let’s use that home
directory for our example.
Create a text file in the users home directory and take a snapshot – call the snapshot
‘snap1’
Take another snapshot, call it snap2, and confirm your snapshots again.
Now let’s run the diff command and see what happens.
Note: I planned this lab to just incorporate the files we created but since we’re on a
laptop the profile-5000-charging.csv file kind of popped in there, you may or may not
have that file in your output.
6.8 Compression
Compression is a useful feature integrated with the ZFS file system. ZFS allows both
compressed and noncompressed data to coexist. By turning on the compression
property, all new blocks written will be compressed while the existing blocks will
remain in their original state.
Let’s create a 500MB file we can do some compression on. Type the following
commands:
Now let's turn on compression for datapool/bob and copy the original 500MB file.
Verify that you now have 2 separate 500MB files when this is done.
There are now 2 different 500MB files in /datapool/bob, but the ls command only
says 500MB is used. It turns out that mkfile creates a file filled with zeroes. Those
compress extremely well - too well, as they take up no space at all.
That concludes this lab on the ZFS File system, run this command to clean up the
work we did during the course of the lab.
7 Summary
In this lab you learned about the power of the ZFS File System in Oracle Solaris 11.
We discussed and performed exercises to familiarize you with zpools and virtual
devices (vdevs). We learned about ZFS datasets like snapshots and clones. You
were also exposed to the myriad of ZFS properties and ways that ZFS can easily be
updated.
The exercises were meant to provide initial exposure to these features and
hopefully a basis for continued learning and eventual expertise in this powerful
storage technology that’s an integral part of Oracle Solaris 11.
8 Resources
For more information and next steps, please consult additional resources: Click the
hyperlinks to access the resource.
Oracle Solaris 11 ZFS Technology Page – articles whitepapers, and more on ZFS
ZFS Best Practices Guide – excellent real world reference for all things ZFS
ZFS Evil Tuning Guide – great resource for detailed tuning and hard to find
Oracle Solaris 11 ZFS Administration – Oracle University 4 day ILT training on ZFS