You've read about ZFS, the advanced storage management facility baked into Sun Microsystems' Solaris Unix operating system. It is Sun's invention, yet Sun has opened it to the world, including ZFS with the mass of Solaris code that Sun has open-sourced.

ZFS has been reported to be much faster than other file systems. That basic tidbit creates a pair of misconceptions about ZFS: First, that it is all about speed, and second, that ZFS is a file system. Neither speaks to the core purpose or advantage of ZFS.

Where speed is concerned, ZFS is as fast as your disks, controllers, and device drivers. It is subject to the same hardware bottlenecks as all other means of managing storage. ZFS is also not what the majority of people, even in IT, understand as a file system. In most instances, a file system is a fixed structure laid down on a blank disk that has been split into partitions or slices. One formats a partition to create a file system, and that file system is a prerequisite for the storage of files. Without the file system, a computer wouldn't know where its files live.

ZFS tosses common understanding about file systems out the window. It begins with pools of storage. The definition of a pool is one of ZFS's most confounding aspects, but it is key to ZFS's unlimited flexibility. A ZFS pool is made up of any combination of devices, real or logical, that provide persistent storage. ZFS can take a bunch of raw disks and string them together into a striped RAID pool, with the protection of mirroring or single or double parity. A ZFS pool can be an arbitrary collection of partitions within disks. A pool can be made from an assortment of ordinary files. And a single pool can contain any mix of the device types I've described. If it presents to the system as a disk or a file, ZFS can stuff it in a pool.

A ZFS pool is handled as its name implies. It's a big vat of persistent storage that you can tap to create a hierarchical structure of directories and files, which brings us to the file system part of ZFS. But it isn't a file system as you know it.

One doesn't fill buckets of finite size from a ZFS pool the way you would with any other variety of software or hardware RAID. Instead, a ZFS pool is structured like a municipal water system. The reservoir is shared by all consumers, any one of whom can drain the whole pool or use just a bit of it. What you'd associate with a file system is really just a name tag, like a street address, used for accounting and administrative convenience, but you can rename, remove, and add file systems to a ZFS pool at will - and nondestructively while the storage is in active use. You can add storage to a pool at any time, and it is immediately available to all file systems in the pool. There is no delay for formatting because ZFS doesn't format.

It is possible to set up ZFS file systems to work as allocated storage with hard or soft limits imposed on file system nodes and on users that store data on those nodes. If you're particularly fond of limits, ZFS can create file systems that behave exactly like old-fashioned mountable volumes built on formatted partitions, but this is only a mirage. ZFS remains limitlessly flexible even when its capabilities are masked to fit the preferences of the administrator. But there's rarely a need to do this because ZFS is easy enough for a child to manage. Seriously, two commands with blissfully simple syntax run the whole show. See Paul Venezia's screencast of ZFS in action for an example.

More than anything, ZFS is unlimited. Pools can span practically infinite numbers of devices and quantities of storage. Each pool can have a practically limitless amount of file systems on it. In this context, the word "practically" refers to the bounds of practicality, such as the number of 3.5-inch hard drives that one can pack into a football stadium.

Explaining ZFS in one article is difficult only because it is so capable. The best way to sum up ZFS is that it makes it possible to do anything, no matter how insane, with persistent storage. If you haven't checked out ZFS yet, do, because it will eventually become ubiquitously implemented in IT. It is too brilliant not to be.