ZFS: More Than Just a Filesystem

When NASDEV was first built, the storage requirement seemed fairly straightforward.

Put some disks in a machine, create a filesystem, share the storage over the network and keep everything backed up.

That sounds simple enough.

Then I started working seriously with ZFS.

It quickly became apparent that ZFS wasn't simply another filesystem. It represented a fundamentally different way of thinking about storage.

From Disks to a Storage Pool

Traditional storage administration tends to make you think in terms of individual disks and volumes.

You have a disk.

You partition it.

You create a volume.

You create a filesystem.

You put data on it.

ZFS changes that relationship.

Instead of treating each disk as an independent storage device, ZFS allows disks to be combined into a storage pool, or zpool.

The pool becomes the underlying storage resource.

Filesystems can then be created within that pool as required.

This is a deceptively powerful concept.

Rather than having to decide in advance exactly how much storage each filesystem needs, storage can be allocated from the common pool.

That flexibility has been particularly useful for NASDEV as its requirements have changed over the years.

The Filesystem Becomes Part of the Storage Architecture

One of the things I like most about ZFS is that the distinction between "filesystem management" and "storage management" becomes much less important.

A ZFS dataset is not simply a directory sitting on top of some unknown volume.

It is a managed filesystem with properties that can be configured independently.

Compression can be enabled.

Quotas can be applied.

Snapshots can be created.

Mount points can be controlled.

Permissions and other filesystem characteristics can be managed at the dataset level.

This means that instead of treating storage as one large bucket, NASDEV can divide it into logical datasets based on what the data actually needs.

Data Integrity

For a NAS, protecting data from silent corruption is particularly important.

A filesystem that simply tells you that a file exists isn't necessarily telling you that every bit of that file is still correct.

ZFS approaches this differently.

Data and metadata are protected using checksums.

When data is read, ZFS can verify that what was retrieved is what was originally written.

If the pool has sufficient redundancy, ZFS can also repair corrupted data automatically.

This is one of the features that changed my thinking about storage.

A disk failure is obvious.

Silent corruption is much more difficult to detect.

A system that can detect corruption before it becomes an unrecoverable problem is considerably more useful.

Snapshots

Snapshots are another feature that has become an important part of NASDEV.

A snapshot captures the state of a dataset at a particular point in time.

The important thing is that creating a snapshot doesn't require copying every file.

Instead, ZFS uses its copy-on-write architecture to preserve the blocks required to represent the previous state.

That makes snapshots extremely practical.

A snapshot can be created quickly and can provide a point-in-time view of the data.

This is particularly useful when experimenting with configurations or making significant changes.

If something goes wrong, the previous state is still available.

Of course, a snapshot isn't a substitute for a backup.

If the storage pool disappears, the snapshots disappear with it.

But as a first line of defence against accidental deletion or unwanted changes, they are extremely useful.

Copy-on-Write

The technology behind much of this is copy-on-write.

Rather than overwriting existing blocks, ZFS writes changed data to new locations and updates the filesystem structure to reference the new blocks.

The old blocks can then remain available to snapshots.

This architecture provides some very useful characteristics.

It makes snapshots practical.

It helps maintain filesystem consistency.

And it provides the foundation for many of the data-integrity features that make ZFS different from traditional filesystems.

There are trade-offs, of course.

Storage management is never completely free.

But for NASDEV, the benefits have been well worth it.

Compression

Another feature I use extensively is compression.

At first, compression sounds like something you would enable simply to save disk space.

It can certainly do that.

But there is another benefit.

If data can be compressed before being written to disk, less physical data has to be transferred to and from the storage devices.

For many workloads, this can actually improve performance rather than reduce it.

Modern processors are very good at compression.

Spending some CPU time to avoid unnecessary disk I/O can be a very worthwhile trade.

For NASDEV, this is another example of why ZFS is more than just a filesystem.

The filesystem itself is actively participating in the storage strategy.

Pools Can Evolve

NASDEV has also benefited from the ability to evolve its storage over time.

The original storage configuration is not the configuration that exists today.

Disks have been replaced.

Capacity has increased.

The pool has evolved.

This is one of the realities of running a system for many years.

Storage requirements rarely remain constant.

A NAS that has plenty of capacity today can look very different several years later.

ZFS doesn't eliminate the challenges associated with storage expansion, but it provides a much more flexible framework in which to manage that evolution.

Performance Isn't Everything

One of the lessons I have learned from NASDEV is that storage performance isn't simply about benchmark numbers.

A system that can deliver impressive sequential throughput but doesn't protect the data particularly well isn't necessarily a good storage system.

For NASDEV, I care about several things:

Data integrity.

Recoverability.

Manageability.

Capacity.

Performance.

And importantly:

Understanding what the storage system is actually doing.

ZFS gives me tools and visibility into all of those areas.

ZFS Has Its Own Learning Curve

ZFS isn't magic.

There are concepts that need to be understood before making significant changes to a production pool.

Pools, vdevs, datasets, snapshots, properties, redundancy and expansion all have their own rules.

Some operations that sound simple can have significant consequences.

That's why one of the goals of this site is to document the things I learn while actually operating NASDEV.

The intention isn't to produce a generic ZFS manual.

There are already plenty of those.

Instead, I want to document what happens when you actually run ZFS for years in a real system.

The upgrades.

The failures.

The recovery.

The performance considerations.

And occasionally the mistakes.

Why ZFS Remains at the Centre of NASDEV

NASDEV started as a network storage project.

It has since grown into something considerably larger.

But storage remains at its centre.

ZFS provides the foundation on which that storage is built, and after years of using it, I still find the architecture remarkably elegant.

The important thing isn't simply that ZFS provides a filesystem.

It is that ZFS treats storage as an integrated system rather than a collection of unrelated layers.

That philosophy fits NASDEV very well.

And as the project continues to evolve, ZFS will remain one of the technologies I document most extensively.