Oracle Blog

Useful stuff for your blog-reading pleasure.

Thursday Sep 06, 2007

So you're now curious about ZFS. Maybe you read Jonathan's latest blog entry on ZFS or you've followed some other buzz on the Solaris ZFS file system or maybe you saw a friend using it. Now it's time for you to try it out yourself. It's easy and here are seven tips to get you started quickly and effortlessly:

1. Check out what Solaris ZFS can do for you

First, try to compose yourself a picture of what the Solaris ZFS filesystem is, what features it has and how it can work to your advantage. Check out the CSI:Munich video for a fun demo on how Solaris ZFS can turn 12 cheap USB memory sticks into highly available, enterprise-class, robust storage. Of course, what works with USB sticks also works with your own harddisks or any other storage device. Also, there are great ZFS screencasts that show you some more powerful features in an easy to follow way. Finally, there's a nice writeup on "What is ZFS?" at the OpenSolaris ZFS Community's homepage.

3. Dive into the pool

Solaris ZFS manages your storage devices in pools. Pools are a convenient way of abstracting storage hardware and turning it into a repository of blocks to store your data in. Each pool takes a number of devices and applies an availability scheme (or none) to it. Pools can then be easily expanded by adding more disks to them. Use pools to manage your hardware and its availability properties. You could create a mirrored pool for data that should be protected against disk failure and that needs fast access to hardware. Then, you could add another pool using RAID-Z (which is similar, but better than RAID-5) for data that needs to be protected but where performance is not the first priority. For scratch, test or demo data, a pool without any RAID scheme is ok, too. Pools are easily created:

zpool create mypool mirror c0d0 c1d0

Will create a mirror out of the two disk devices c0d0 and c1d0. Similarly, you can easily create a RAID-Z pool by saying:

zpool create mypool raidz c0d0 c1d0 c2d0

The easiest way to turn a disk into a pool is:

zpool create mypool c0d0

It's that easy. All the complexity of finding, sanity-checking, labeling, formatting and managing disks is hidden behind this simple command.

If you don't have any spare disks to try this out with, then you can just create yourself some files, then use them as if they were block devices:

The cool thing about this procedure is that you can create as many virtual disks as you like and then test ZFS's features such as data integrity, self-healing, hot spares, RAID-Z and RAID-Z2 etc. without having to find any free disks.

When creating a pool for production data, think about redundancy. There are three basic properties to storage: availability, performance and space. And it's a good idea to prioritize them in that order: Make sure you have redundancy (mirroring, RAID-Z, RAID-Z2) so ZFS can self-heal data when stuff goes wrong at the hardware level. Then decide how much performance you want. Generally, mirroring is faster and more flexible than RAID-Z/Z2, especially if the pool is degraded and ZFS needs to reconstruct data. Space is the cheapest of all three, so don't be greedy and try to give priority to the other two. Richard Elling has some great recommendations on RAID, space and MTTDL. Roch has also posted a great article on mirroring vs. RAID-Z.

4. The power to give

Once you have set up your basic pool, you can already access your new ZFS file system: Your pool has been automatically mounted for you in the root directory. If you followed the examples above, then you can just cd to /mypool and start using ZFS!

But there's more: Creating additional ZFS file systems that use your pool's resources is very easy, just say something like:

5. Snapshot early, snapshot often

ZFS snapshots are quick, easy and cheap. Much cheaper than the horrible experience when you realize
that you just deleted a very important file that hasn't been backed
up yet! So, use snapshots whenever you can. If you think about
whether to snapshot or not, just do it. I recently spent only
about $220 on two 320 GB USB disks for my home server to expand my
pool with. At these prices, the time you spend thinking about whether
to snapshot or not may be more worth than just buying more disk.

Again, Chris has some wisdom on this topic in his ZFS
snapshot massacre
blog entry. He once had over 60000 snapshots and he's snapshotting
filesystems by the minute! Since snapshots in ZFS “just work”
and since they only take up the space that actually changes between
snapshots, there's really no reason to not doing snapshots all the
time. Maybe once per minute is a little bit exaggerated, but once a
week, once per day or once an hour per active filesystem is
definitely good advice.

6. See the Synergy

ZFS by itself is very powerful. But the full beauty of it can be
unleashed by combining ZFS with other great Solaris 10 features. Here
are some examples:

Tim Foster has written a great SMF
service that will snapshot your ZFS filesystems on a regular basis.
It's fully automatic, configurable and integrated with SMF in a
beautiful way.

ZFS can create block devices, too. They are called zvols. Since
Nevada build 54, they are fully integrated into the Solaris iSCSI
infrastructure. See Ben
Rockwood's blog entry on the beauty of iSCSI with ZFS.

A couple of people are now elevating this concept even further:
Take two Thumpers, create big zvols inside them, export them through
iSCSI and mirror over them with ZFS on a server. You'll get a huge,
distributed storage subsystem that can be easily exported and imported
on a regular network. A poor man's SAN and a powerful shared storage
for future HA clusters thanks to ZFS, iSCSI and Thumper! Jörg
Möllenkamp is taking this concept a bit further by thinking
about ZFS, iSCSI, Thumper and SAM-FS.

ZFS and boot support is still in the works, but if you're brave, you can try it out with the newer Solaris Nevada distributions on x64 systems. Think about the possibilities together with Solaris Live Upgrade!
Create a new boot environment in seconds while not needing to find or
dedicate a new partition, thanks to snapshots, while saving most of the
needed disk space!

And that's only the beginning. As ZFS becomes more and more adopted, we'll see many more creative uses of ZFS with other Solaris 10 technologies and other OSes.

7. Beam me up, ZFS!

One of the most amazing
features of ZFS is zfs send/receive.
zfs send
will turn a ZFS filesystem into a bitstream that you can save to a
file, pipe through bzip2 for compression or send through ssh to a
distant server for archiving or for remote replication through the
corresponding zfs
receive command.
It also supports incremental sending and receiving out of subsequent
snapshots through the -i
modifier.

Easily migrate ZFS filesystems between pools on the same machine
or on distant machines (through ssh) with zfs send/receive.

Create a crontab entry that takes a snapshot every minute, then zfs
send -i it over ssh to a second machine where it is piped into zfs
receive. Tadah! You'll get free, finely-grained, online remote
replication of your precious data.

Easily create efficient full or incremental backups of home
directories (each in their own ZFS filesystems) through ZFS send.
Again, you can compress them and treat them like you would, say, treat
a tar archive.

See? It is easy, isn't it? I hope this guide helps you find your way around the world of ZFS. If you want more, drop by the OpenSolaris ZFS Community, we have a mailing list/forum where bright and friendly people hang out that will be glad to help you.

Thursday Aug 16, 2007

This script recursively copies ZFS filesystems and its snapshots to another pool. It can also generate a new snapshot for you while copying as well as handle unmounts, remounts and SMF services to be temporarily brought down during file system migration. I hope it's useful to you as well![Read More]

Sunday Aug 12, 2007

Last week, I've been interviewed by the german podcast POFACS, the podcast for alternative computer systems. Today, the interview went live, so if you happen to understand the german language and want to learn about ZFS while driving to work or while jogging, you're invited to listen to the interview.

I was actually amazed at how long the interview turned out: It's 40 minutes, while recording the piece only felt like 20 minutes or so. The average commute time in germany is about 20 minutes, so this interview will easily cover both ways to and from work. But there's more: This episode of POFACS also introduces you to the NetBSD operating system, the German Unix User Group GUUG. Finally, the guys at POFACS were also so kind to feature the HELDENFunk podcast in a short introductory interview. Thanks!

So with a total playing time if 1 hour and 20 minutes, this episode has you covered for at least two commutes or a couple of jogging runs :).