10 Reasons You Need to Look at ZFS

Still dithering about Sun's high-performance filesystem? Here are ten reasons to give it a look today.

 By Paul Rubens
Page 1 of 2
Print Article

Sun's open-source ZFS file system has some amazing features. It was originally designed for Solaris and unveiled in 2005, but you'll also find it in OpenSolaris and related distributions. In the future it may well become a popular file system to run with Linux and BSD as well.

Here are the top 10 features that ZFS fans find insanely great:

1. Checksums in Metadata for Data Integrity

Data integrity is of paramount importance in ZFS, and is the driver for many ZFS features.

The file system uses a 256-bit checksum, which is stored as metadata separate from the data it relates to, when it writes information to disk. Unlike a simple disk block checksum, this can detect phantom writes, misdirected reads and writes,  DMA parity errors, driver bugs and accidental overwrites as well as traditional "bit rot."

2. Copy on Write

ZFS ensures that data is always consistent on the disk using a number of techniques, including copy-on-write. What this means is that when data is changed it is not overwritten — it is always written to a new block and checksummed before pointers to the data are changed. The old data may be retained, creating snapshots of the file system through time as changes are made. File writes using ZFS are transactional — either everything or nothing is written to disk.

3. Data Snapshots With Time Slider

The latest version of OpenSolaris illustrates the power for ZFS's snapshots capability with a small graphical application called TimeSlider. ZFS can be configured to take a snapshot of the file system (or a section of it, such as just a user's home folder) on a regular basis — every 15 minutes, or every hour, and so on. These snapshots are very small and efficient, as only the deltas from the previous snapshot are stored.

TimeSlider offers a view of the file system (or a home folder), with a slider which can be moved back along a timeline to earlier snapshot times. As this is done, the view changes to show they state of the file system or the contents of a folder at the corresponding snapshot time. Recovering a file that has been overwritten by mistake or rolling back the system after an unsuccessful update is then just a matter of moving the slider back to the appropriate snapshot time.

Snapshots can also be made writable to create clones of existing file systems.

4. Pooled Data Storage

ZFS takes available storage drives and pools them together as a single resource, called a zpool. This can be optimized for capacity, or I/O performance, or redundancy, using striping, mirroring or some form of RAID. If more storage is needed then more drives can simply be added to the zpool — ZFS sees the new capacity and starts using it automatically, balancing I/O and maximizing throughput.


RAID 5 has a well known flaw called the RAID 5 write hole. This causes a problem when a data block is written to a stripe but a power failure occurs before the corresponding parity block can be written. As a result the data and parity for the stripe will be inconsistent. If a disk then fails, the RAID reconstruction process will result in incorrect data. The only way out of this is if an entire stripe happens to be overwritten, thus generating a correct parity block.

RAIDZ gets around this problem by using a variable width stripe, so every write is effectively a full stripe write. This, together with ZFS's copy on write characteristic (mentioned above,) eliminates the RAID 5 write hole completely. RAIDZ2 works in a similar way, but can tolerate the loss of two disks in the array using double parity.

Setting up a RAIDZ (or RAIDZ2) array is very easy and involves issuing one command

This article was originally published on Oct 7, 2009
Get the Latest Scoop with Networking Update Newsletter