From the course: Learning FreeNAS

Understanding ZFS

From the course: Learning FreeNAS

Start my 1-month free trial

Understanding ZFS

- [Instructor] ZFS offers many features for protecting data and managing storage. In most of their filesystems, the filesystem itself isn't aware of the hardware that it's sitting on top of. And the volume manager that manages the disks doesn't have any insight into the files stored on them. ZFS manages both volumes and the filesystem, making it a kind of hybrid between RAID or another volume manager and a regular filesystem. ZFS can scale by adding new disks, and it can accommodate enormous amounts of data. With ZFS, as long as you have enough hard drives, you're not going to run up against any limits anytime soon. But buying all those hard drives might get a little bit expensive. I'd like to take a few minutes to talk about the concepts behind ZFS and how it works. When restoring data, we need disks. These disks are used to create Vdevs, short for virtual devices, which are the basic unit that we work with using ZFS. A Vdev can represent just one disk or a set of disks. Depending on how many disks there are in a Vdev, different options for storing data in redundant and protected ways become available to us. With just one disk, there's no protection against disk failures. With two, we can use mirroring, which writes the same data to both disks, reducing the likelihood that a single disk failure would result in total data loss. Adding more disks, we can add more mirrors, or we can have ZFS store the data across the disks using standard RAID or RAIDZ. This arrangement creates redundancy of data across the disks, and includes recovery information as well, which allows the system to rebuild the data if some of those segments are lost, or if a whole disk is lost. Vdevs organize space into blocks of storage called Metaslabs, and from those blocks we create pools to act as data stores. Pools act as an organizational unit representing the storage space on a set of disks. Pools are distributed across one or more Vdevs, and ZFS keeps track of the health of pools and manages their integrity. Pools are isolated from each other, and they can be moved between Vdevs, or they can be extended by adding more Vdevs to the pool. We can't add additional disks to existing Vdevs, but we can replace disks if a disk inside of one fails. When new storage is introduced, either by replacing a disk in a Vdev or adding a new Vdev to a pool, ZFS copies the appropriate data to it in a process called resilvering. We can take snapshots of pools called checkpoints representing their state at a specific point in time. ZFS can automatically perform scrubbing on pools to make sure that the data stored in them is intact. Inside of pools, we either create datasets or volumes. A dataset contains a filesystem, and a volume, often called a zvol, is a block device. Datasets don't have a preset size, and if there are more than one, they share space inside the pool until the pool is filled up. We can nest datasets inside one another. And we can set quotas for datasets so they don't grow too large. But they don't have a fixed size to begin with, zvols, on the other hand, do have a fixed size. We can also take snapshots of datasets and volumes. Snapshots are a record of the state of the data at a moment in time. They don't take up very much space and can be completed quickly, making them a useful tool for restoring deleted or modified files, or as a source for periodic backups of information. ZFS monitors all the levels that it manages, making sure the disks are healthy using monitoring technologies like SMART. It keeps an eye on the integrity of Vdevs and performs scrubbing to ensure that pools are healthy. ZFS will let us know if a pool is damaged or degraded due to underlying problems with the disks. And ZFS tracks to make sure the data blocks match their check zones and haven't deteriorated. ZFS handles most routine errors automatically and it notifies us if there's a failure that it can't recover. If an error that ZFS can't fix occurs, we can use tools provided with ZFS to replace disks, perform scrubbing, and so on. ZFS also provides us the tools to create new Vdevs, add them to pools, and more. ZFS also includes the concepts of cache and logs. These are read caches and write caches, respectively. The read cache, called ARC, or adaptive read cache, is a portion of RAM where frequently accessed data is staged for fast retrieval. This can be extended to a disk-based device with L2ARC, or level two ARC. This kind of cache is a Vdev made of fast storage, often SSDs optimized for read speed. Whereas most of the time Vdevs should be mirrors or redundant sets of disks, the L2ARC can just be a single disk or a stripe of disks. And that's because if the cache device fails, all you lose is the read cache, not any of the data on the pool. Logs are areas where synchronous writes are kept until they're able to be committed to storage. ZFS uses a ZFS Intent Log, or a ZIL, to capture these writes and group them into transactions to save them to the pool. The speed of this operation can be increased by adding an SLOG or separate log device, which is often a mirror of two small SSDs, which are optimized for write speed. We can add cache and log devices to a pool when we create it, or we can extend a pool to include them if we discover a need for them later. Additional cache and log devices are by no means required to use ZFS, but for high traffic environments, they provide an administrator with some very useful performance tuning options. While there are many more details to the implementation of ZFS, these basic terms and concepts should get us started administering a storage system.

Contents