...
h1. ZFS Basics Demo (12 minutes)
h4. Description
This demo showcases some of the cool features of ZFS - easy administration, snapshots, backups, rollback, working with pools and mirrors.
h4. OpenSolaris Versions Supported
OpenSolaris 2008.05 or higher.
h4. Points to Hit
* ZFS is very cool
* ZFS is easy to administer
* Snapshots are cheap, fast and easy to create
* You can backup snapshots including incremental snapshots
* Rollbacks also take less than a second independent on data size
* Working with storage pools is easy
* You can create a mirror in few seconds
* You can grown storage pools easily
* More reasons for ZFS: [http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf]
h4. Demo Prep
Using VirtualBox's Virtual Disk Manager, create 4 dynamically expanding 1GB disks (ZFSDemo1.vdi, ZFSDemo2.vdi, ZFSDemo3.vdi and ZFSDemo4.vdi). They will be used for the RAID. The type should be SATA. !Screenshot-OpenSolaris2008.05BTS-Settings.png!
Optionally, since this demo uses ls, configure [ls colors|http://blogs.sun.com/observatory/entry/ls_colors].
Note, this demo could also be done using USB sticks, however, I prefer to use a virtual image as it presents "cleaner" output. For example, as I have Time Slider enabled, the output from 'zfs list \-t all' is harder to weed though.
h4. Gotchas
None known.
h4. Demo
* Open a terminal and enlarge it (Ctrl Shift \+)
* *pfexec su* to avoid having to using pfexec.
h4. Working with Pools
We start by looking at our existing pool and cover the steps required to create a new pool. The new pool will be a mirrored pool. First, look at the existing pool:
* Run *zpool list* to see the existing pool (on a default install, this will be rpool)
* Run *zpool status* to see the health status of the pool
Let's create a new mirrored pool:
* Run *format* to get the device names. Note, c = controller number, t = target number, d = logical unit number (or ask the audience if they remember what command to run to get the device names).
* Run *zpool create \-f demo mirror device1 device2*.
* Run *zpool list* and note the 1GB available.
* Run *zpool status demo* to view the disks in the new pool.
* Run *zpool add \-f demo mirror device3 device4*.
* Run *zool list* and show the available size has been doubled.
* Run *zpool status demo* to view the disks added to the pool.
* Mention other features: clones, export/import, compression, encryption, quotas and raidz. For details about these features see the ZFS preso: [http://opensolaris.org/os/community/zfs/docs/zfs_last.pdf]
h5.
h5. Working with File Systems and Snapshots
Note, as part of the pool creation process, a file system was also created and mounted. Not bad - one command to do all that.
* Run *zfs list* to show the file systems, including the new *demo* file system that was just created. Explain that the first column is the dataset name, comprised of the <pool name>/<file system name>. Explain that the last column is the mount point. Explain why all active file systems have the same amount of GB available (because they use the same storage pool). This could also be posed as a question to the audience, to make sure they were paying attention during your presentation :-) .
* Create a new FS by running *zfs create demo/myfs*. By default, this will mount the myfs directory at (/demo/myfs). Alternatively, you can show that it is possible to mount the directory anywhere, independent of the pool structure, using the {{mountpoint}} option, e.g., *zfs create \-o mountpoint=/export/myfs demo/myfs*.
* Note how fast it was to create the new file system - you can create file systems like directories.
* Run *zfs list* to show the new FS.
* Run *cd /demo/myfs* and *ls*. The directory is empty.
* Run *touch file1.txt*. Edit it's contents to say something.
* Run *mkfile 100M large-file*. Then run *ls*. Mention no formatting was necessary (as is required for all other new file systems before they can be used). Optionally, edit the file's contents: "Before snapshot".
* Run *zfs snapshot demo/myfs@today*.
* Run *zfs list \-t all \| grep demo* to see the snapshot that was created.
* Run *touch file2.txt* and *rm file1.txt* (or edit it's contents: "After snapshot"). Then run *ls*.
* Run *zfs list \-t all \| grep demo*. Note the snapshot isn't taking up any space. This is because all of its contents are still intact (file1.txt).
* Run *zfs rollback demo/myfs@today*. Then run *ls*. Only file1.txt should be there. Mention advantages of instantaneous snapshots and rollbacks.
* Run *zfs list*. Note the snapshot is using 0K again.
h5. Working with Large Snapshots
Tell the audience that they might not believe you that the snapshots are so fast because we are just working with empty files. So let's try something brutal - delete the /opt directory.
* As of 2008.11, the opt directory is no longer a separate file system.
* Run *zfs snapshot rpool/ROOT/opensolaris@today*.
* Run *du \-hs /opt* to show it's current size.
* Run *cd /opt* and *ls*.
* Delete all files in /opt by running *rm \-rf \**. Run \*ls*.
* Run *zfs list*. Note how the snapshot is now using several hundred megabytes.
* Run *zfs rollback rpool/ROOT/opensolaris@today*. Run *ls*. Show that all files have been recovered. Mention the operation that took the longest time was deleting the files.
h5. Backup and Restore
What if I want to make a backup and move my file system as a whole?
* Run *zfs send demo/myfs@today > /tmp/zfsdata*.
* Run *zfs destroy \-r demo/myfs*. Explain the \-r option recursively destroys all children, including snapshots.
* Run *zfs list*.
* Run *ls /demo/myfs*.
* Run *zfs receive \-d demo < /tmp/zfsdata*. The {{\-d}} option also causes the snapshot to be created.
* Run *ls /demo/myfs*.