ZFS Plugin For OMV7

The ZFS plugin makes it easy for users to take advantage of ZFS, with an easy installation and making ZFS's more important features available within Openmediavault's GUI.

ZFS (the Zettabyte File System) is a high-performance, scalable file system and logical volume manager designed by Sun Microsystems which is now part of Oracle. It was originally developed for the Solaris operating system and it's the Granddaddy of COW (Copy On Write) filesystems. ZFS has since been ported to other platforms, it include Linux and FreeBSD . Having been under constant development since it's creation for Sun Solaris server in 2001, ZFS is very mature.

Currently, OPENZFS on Linux is sponsored by Lawrence Livermore Labs, it's very well funded and will be fully supported into the foreseeable future and, likely, beyond.

Following are some key features and characteristics of ZFS:

• Data Integrity: ZFS uses a copy-on-write mechanism and checksums for all data and metadata, ensuring that any corruption can be detected and corrected.
• Snapshots and Clones: ZFS allows for the creation of snapshots, which are read-only copies of the file system at a specific point in time. Clones are writable copies of snapshots, enabling efficient data management and backup.
• Pooled Storage: ZFS combines the concepts of file systems and volume management, allowing multiple file systems to share the same storage pool. This simplifies storage management and improves efficiency.
• Scalability: ZFS is designed to handle large amounts of data, making it suitable for enterprise-level storage solutions. It can manage petabytes of data and supports very large file systems.
• RAID Functionality: ZFS includes built-in RAID capabilities, allowing users to configure redundancy and improve data availability without the need for separate hardware RAID controllers.
• Compression and Deduplication: ZFS supports data compression and deduplication, which can save storage space and improve performance.
• Self-Healing: When ZFS detects data corruption, it can automatically repair the affected data using redundant copies, enhancing data reliability.

More detailed information on capabilities and limitations is available → here.

• PuTTY is a prerequisite for installing OMV-Extras and for working with ZFS on the command line.
  PuTTY is an SSH client that will allow users to connect to their SBC, from a Windows client, to get on the server's command line. PuTTY is installable on a Windows client. Installation and use guidance, for PuTTY, can be found →here.
• OMV-Extras is a prerequisite for installing the kernel plugin. Installation and use guidance, for the OMV-Extras plugin can be found →here.
• The Kernel Plugin is required for ZFS. After OMV-Extras is installed, on OMV's left side menu bar go to System, Plugins. Find, select, and install the openmediavault-kernel 7.x.x plugin.

With a focus on getting new users started:
Most of the documentation at OMV-Extras.org is written with a focus on “How-To” do a specific task. Further, in most cases, topics on this site are geared toward beginners. While getting to a running ZFS installation can be laid out in a “How-To” format, ZFS and it's RAID equivalents are NOT beginner topics. Accordingly, this document will have the “How-To” route along with explanations (very brief in nature) to inform beginners of ZFS basics and to prevent users from straying too far from reasonable norm's during setting up.

As the “How-To” path is laid out, links to overview explanations of key concepts are provided. For beginners and others who have had little to no exposure to ZFS, taking a few minutes to read and understand ZFS related concepts will increase understanding and dispel some the myths and mysticism related to this unique file system.

There are a great many misunderstandings with regard to ZFS. This section will go over a few of them.

(TL;DR - send me to → Kernels and Their Impact.)

“I heard that ZFS requires massive amounts of ram” or “ZFS requires a strong CPU”.
While all use cases are not the same, for this sake of this discussion, we'll assume that users reading this document are NOT Corporate or Datacenter Admins. The assumption will be that readers are home server users, server admins for small businesses, or other entities that have 25 users or less. In other words, when compared to Enterprise level network traffic, we're talking about relatively “light usage”.

The author of this document, in personal experience with running ZFS, has set up a 4TB pool on a host with 4GB of ram and an older Atom processor (read, a weak CPU). Performance for a few users, along with streaming data, was fine. Memory might become an issue only if “dedup” (deduplication of data) is turned ON. (This is an Enterprise feature that is OFF by default.) In most home or small business use cases, ZFS' CPU requirements are modest.

“ECC RAM is required to run ZFS”.
As is the case with most file server and NAS installations, ECC is desirable but not required. ECC is geared toward correcting randomly “flipped bits” in RAM, notionally caused by cosmic rays. While flipped RAM bits could cause an errored disk write, a more likely outcome would be an kernel or application error. Data stored and checksumed, on a spinning hard drive or an SSD, is another matter altogether. Correcting storage media errors is a task that ZFS handles well.

“ZFS is eating all of my RAM!”
Actually, this is a good thing. If memory is unused and ZFS needs RAM for house keeping chores (a scrub for example) or for a copying operation, ZFS will use existing RAM to facilitate and speed up I/O. Further, ZFS will hold the same RAM until another process requests RAM. At that point ZFS will release RAM to the requesting process. Assuming that a reasonable amount of ram has been provisioned (4GB or more), even if most of a ZFS server's ram “appears” to be in use, there's nothing to worry about.

ZFS is licensed under CDDL which is a “free” open source license. Due to a perceived (but never tested in a Court of Law) licensing conflict, Debian Linux does not build ZFS kernel modules into their kernels by default. This is more of a “legal fiction”, than anything else, in that the OpenZFS license is simply another version of several “free open source” licenses, not unlike Debian's GNU General Public license and a hand full of other free OSS licenses contained within the Debian distro's (as outlined →here). Since Openmediavault is based on Debian Linux, ZFS is provided as a plugin to prevent any issue that may result from a licensing conflict.

In the final analysis, for the end user, this free license “wrangling” is a non-issue.

TL;DR: I'll chose my kernel. Send me to → Installation.

Openmediavault installs with the Debian Backports kernel, by default. The standard Debian kernel is available, but must be selected. A third option, the Proxmox kernel, is installable VIA the kernel plugin.
Where ZFS is concerned, following are the pro's and con's of each kernel:

The Backports Kernel (OMV's default kernel) is used, primarily for it's support of the latest hardware and, along similar lines, for the latest software packages. The issue with the backports kernel, where ZFS is concerned, is that it's possible to have a kernel upgrade offered for installation that does not have ZFS packages in its repo's. (This has happened to the author of this doc.) After a backports kernel upgrade, this may result in a ZFS pool “disappearing”. The pool still exists but, “fixing the issue” requires booting into an older kernel, to see the existing pool, until the new kernel's ZFS repository packages “catch up”. For this reason alone, the backports kernel is not recommended.

The Standard Debian Kernel (selectable) can be used for ZFS. However, since ZFS kernel modules are not installed in the Debian kernel by default, they must be built by the ZFS plugin when it is installed. While this process works, building the modules is a long process that requires continuous access to online repo's. Accordingly, the potential for a build error exists. For this reason, while the Standard Kernel is very usable for ZFS, it is not ideal.

The Proxmox Kernel is a Ubuntu Kernel that has ZFS modules prebuilt and compiled into the kernel by default. However, the Kernel plugin is required to install the Proxmox Kernel. Among the other useful features available, the kernel plugin can pull and install a Proxmox kernel, and can make it the default kernel when booting. As Proxmox kernel upgrades become available and are performed, the repo's for the kernel will always have the required packages to support ZFS. Further, since the Proxmox kernel is financially supported by the Proxmox Virtualization project, the kernel is exhaustively tested with ZFS modules installed, before it's made available to the public. In the bottom line, using the Proxmox kernel decreases the possibility of an installation error and guarantees ZFS support through kernel upgrades, while increasing overall server reliability.

ZFS with the backports Debian kernel: This is a bad idea. Problems are possible with each backports kernel update.
ZFS with the standard Debian kernel: This combination will work, but it's not ideal.
ZFS with the Proxmox kernel: This is the best case scenario for ZFS.

To get started with ZFS and to create an easy installation path to the most stable server possible, some preliminary setup, settings and adjustments are recommended.

First, bring the server up-to-date by applying all pending updates: Under System, Update Management, Updates, click the Install Updates button. Confirm and Yes.
(Depending on the number of updates pending, this may take some time. If the installation is new with several updates pending, it may take more than one update session to fully update the server.)

At this point, a user choice must be made:

• If the Standaard Debian kernel is to be used, proceed with Disable Backports directly below.
  

• If the Proxmox kernel is to be used (recommended), skip to → Install The Proxmox Kernel.
  

As previously mentioned, in preparing to install ZFS, disabling backports kernels is highly recommend.

Under System, OMV-Extras, click on Disable backports
(This may take a few minutes to complete. At the end of the process, End of Line will appear. Clicking the Close button will finish the process.)



Since the above process changes software repositories, click on apt clean repos and apt clean.
While it's not absolutely necessary, to insure that the standard Debian kernel and it's repo's are aligned, consider rebooting the server.

When complete, skip the following and proceed directly to Installing the ZFS Plugin.

Under System, Kernel, select the download Proxmox icon and select a kernel.
(While this selection is the users choice; the oldest kernel may result in an avoidable kernel upgrade in the near future while the newest kernel will not be as well tested in the field conditions. The “middle of the road” kernel is recommended.)


The dialog box will recommend rebooting to complete the installation of the Proxmox kernel. Reboot now.

After the reboot is complete, under System, Update Management, Updates, check for updates.
It is likely that Proxmox related updates will be available. Install these updates.

Under System, Kernel, take note of the kernels available.

The kernel ending with -pve is the Proxmox kernel and it is, now, the default.

Optional: Non Proxmox kernels can be removed.

TL;DR proceed to → Installing the ZFS plugin.

Removing non-proxmox kernels is recommended in that, when Openmediavault is updated, the remaining Debian kernels will be updated as well. These updates will also update the grub bootloader with unnecessary entries for the newer Debian Kernels. While rare, occasionally, grub/kernel updates do not go well. Issues with unused Debian Kernels and their grub updates can be prevented by removing non-proxmox kernels.

To remove non-proxmox kernels: Under System, Kernel, click on the Proxmox icon and select Remove non-Proxmox Kernels from the menu.


When the popup dialog displays END OF LINE, click the Close button.

Reboot.

Under System, Kernel: Only Proxmox kernels should be displayed (ending with -pve), along with memory testing utilities and other utilities that may have been previously installed.

Under System, Plugins, scroll all the way to the bottom. Highlight openmediavault-zfs 7.X.X and click the down arrow to install.

The installation pop up will proceed until END OF LINE appears. At that point, click the Close button.
In most cases, the GUI will reset which changes the left side menu, adding ZFS to the Storage Pop down.

- A ZFS “Pool” is made up of one or more “VDEV's”. More detailed information on VDEV's can be found → here. It's recommended that users reveiw the various VDEV types as their selections may have an impact on future Pool expansions.
- During the creation of a “Pool”, in accordance with user selections, the installation process creates and add's the first VDEV automatically.
- A pool can have one or more VDEV's and a new VDEV can be added to an existing pool, at any time, increasing the pool's size.

Under Storage, ZFS, Pools, click on the create (+) icon.

The “Create” window will pop up. Note that making selections on this page will create a pool and the first “vdev”. (More on vdev's later.)

Name:
The user's choice. However, limit the name to letters and numbers, with a reasonable length.

Pool type:

The choices are; Basic, Mirror, RAIDZ1, RAIDZ2, RAIDZ3
For more details on the these selections, see → link.

Devices:
When clicked, a list of available drives will pop up.

To see and select drives in this field, they must be wiped under Storage, Disks. Generally, a Quick wipe will do.

Mountpoint:
If left blank (recommended) the pool will be mounted, by name, at the root of the boot drive.

Device alias:
This will be used to name devices (hard drives). Leaving at default is recommended.

Force creation:
Checking this box should not be necessary and is not recommended.

Set ashift: Checking this box is HIGHLY recommend. Checking the box will set ashift to 12 which sets the sector size (4K) of most current spinning hard drives and SSD's. (More information on ashift is available → here.

If the box is not checked, the default ashift value passed to the pool will be 0. As noted in the previous link, this will not be good for performance.

Compression:
Optional. However checking this box may have the effect of saving some drive/pool space. When this box is checked, lz4 is the offered default. LZ4 is a good overall choice for speed and efficiency with little to no performance penalty.

If a warning pops up containing “invalid VDEV specification”, it may be necessary to check the FORCE box.

TL;DR Take me to → Adding Filesystems.

Note that it's possible to created Linux shared folders at the root of a pool. However creating ZFS “filesystems” has numerous advantages. ZFS filesystems can have assignable properties and each filesystem can “inherit” global properies from the Pool. One of the more important features of ZFS filesystems is that each filesystem can have it's own snapshots.

As a matter of practice and organization, filesystems scan be setup to contain and segregate “data types”, such as Documents, Music, Pictures, Videos, etc. With individually assigned properites, ZFS filesystems and snapshots can be setup to accomodate eash type.

Under, Storage, ZFS, Pools; Click the “+” (add) icon.

In the Add dialog, give the Filesystem a name, and click Add.



Confirm the Pending Change.

Repeat as needed for the filesystems necessary for the use case.

General:
As noted before, when creating the first Pool a new VDEV is created within the new pool in accordance with the user's selections.
There are a few rules concerning Pools and VDEV's.

First: If a VDEV is lost, the Pool is lost. There is no recovery from this situation.
Second: Disk redundancy is at the VDEV level. If redundancy is not used, the failure of one disk will result in the failure of the Pool.
Therefore, while possible, it wouldn't be advisable to expand a Pool with an existing RAID VDEV, using a single Basic volume because a basic volume has no redundancy.

• VDEV's are made up of physical block devices, I.E storage drive(s).
• A Pool can be expanded by adding new VDEV's. However, the addition of a VDEV, to a Pool, is PERMANENT. A VDEV can not be removed from a Pool.
• A VDEV, once created, can not be changed. A Basic volume with remain a Basic volume. A mirror (RAID1 equivalent) will remain a mirror. RAID-Z1 (a RAID5 equivalent) will remain RAIDZ1. RAIDZ1 can not be upgraded to RAID-Z2 (a RAID6 equivalent), etc.
• If a single VDEV is lost, in a multi-VDEV Pool, the entire Pool is lost.
• Disk redundancy is at the VDEV level. Accordingly, it makes no sense to add a Basic disk VDEV, to a RAID level VDEV, to expand a Pool. Per the rules, a VDEV can't be removed and if the Basic (single disk) fails, the entire Pool will be lost.
  

• Basic:

Basic is a single disk volume. A single “Basic” disk is fine for basic storage. A scrub will reveal data integrity errors but, using default attributes, data errors will not be automatically corrected. However, if the filesystem attribute copies=2 is set, that filesystem residing on a Basic volume will autocorrect data errors. (The cost associated with 2 copies of all files is that it uses twice the disk space.) As noted earlier, using a Basic volume to expand a Pool with a RAID VDEV is a bad idea.

• Mirror: Also known as a Zmirror. A Zmirror is a RAID1 equivalent. A mirror requires a 2 disk minimum. In that there are always at least 2 copies of all files in a Mirror, data integrity scrubs automatically correct data errors. Further, it's worth noting that more than 2 disks can be added to a single Mirror. Adding more that 2 disks creates additional disk mirrors and more than 2 copies of all files. While the cost is the loss of hard drive space, multiple drives in a mirror configuration provides for maximum data integrity and safety. For the reasons stated in this → reference, using VDEV(s) comprised of one or more mirrors should be considered and is recommended.
  

For RAIDZ implementations, it is generally recommended to run and “odd” number of drives.

• RAID-Z1: With one striped parity disk, this is the equivalent of RAID5. (RAID-Z1 requires 3 disks minimum. A rule of thumb maximum would be 7 drives.)
  
• RAID-Z2: With two striped parity disks, this is the equivalent of RAID6. (RAID-Z2 requires 4 disks minimum. A rule of thumb maximum would be 11 drives )
  
• RAID-Z3: With three striped parity disks, RAID-Z3 has no RAID equivalent but it could, notionally, be called RAID7. (RAID-Z3 requires 5 disks minimum. A rule of thumb maximum would be 15 drives.)
  

Pools made up of mirrors offer the most features and advantages. Disk redundancy is taken care of and, since there are two copies off all files, bit-rot damage to files is self healing. If needed, another mirror (pair of disks) can be added to expand the pool at any time.

Data Integrity is one of ZFS' hall mark features. In many file systems silent corruption go unnoticed and unchecked, largely because they have no mechanize to detect “bit-rot”. There are numerous reasons for bit-rot having to do with the inevitable degradation of magnetic media due to age, SSD's that have flipped bits from comic rays and other scenarios. Another consideration is the way hard drives and SSD's fail. Contrary to popular belief, storage media does not fail instantly, with a similarity to flipping a light switch. Often they fail slowly and silently, irreversibly corrupting data. Without a filesystem that actively monitors the health of stored data, the discovery of data corruption may be well after sensitive data is irretrievably lost. Again, since corruption is often silent and may occur over an extended period, the potential for copying corrupted files to a backup device is possibility as well.

Conversely, by using file checksums and “scrubs”, ZFS actively monitors the health of user's data. ZFS scrubs may detect issues with a hard drive well before SMART stat's provide warnings of a developing drive issue. Keeping the primary server's data clean, insures that backup copies of data are clean as well.

When a file is copied into a ZFS Pool, the file is parsed and assigned a checksum. A checksum may also be referred to as a “hash”. Every file will have a unique checksum. If a file is modified, a new checksum is calculated and assigned to the file. In this manner, the exact state of the file is tracked as it was when it was created or modified. It's important to note that, with or without modifications by the filesystem, if the file is altered in any respect, even at the bit level, the checksum will change. Changes that did not occur as a result of a filesystem write, is what data integrity is all about.
A housekeeping chore called a “scrub” can be used to compare file checksums against actual file content. Scrub's should be run, periodically, to insure that data is clean and as to serve as a warning of potential degradation of storage media.

In the following illustration:
- The file in the Pool on left matches its checksum. If all files match their checksums a scrub would report scan: scrub repaired 0B in <Length of Time required for the scan> with 0 errors on <Day, Date, Time, Year>
- The file in the Pool on the right does not match it's checksum. Since the Pool has no redundancy, this file might be reported as a “checksum error” and / or an “unrecoverable error”.

File restoration is automatic “if” two copies of the same file exist. Consider the following illustration:

- On the left:
When a file is created a ZFS mirror (RAID1 equivalent) creates two identical copies of the file, on each hard drive, and assigns them identical checksums.
- In the middle:
A scrub took place where one of two files, that where previously identical, no longer matches its checksum.
- On the right:
ZFS will automatically delete the error-ed file and copy the known good file to the 2nd disk.

Automatic file restoration is available under two conditions:
- When using Zmirrors (where there are two copies of all files).
- In all other VDEV's where Basic Volumes or RAIDZX is used, AND where filesystems have the copies=2 feature active.

Consider the following:
In cases where filesystems are using the copies=2 feature, auotmatic file restoration works the same as it would with Zmirrors where 2 file copies exist natively.

Practical considerations:
- While copies=2 can be used with a Basic volume, it should be noted that in the event of a disk failure both file copies would be lost. However, if data integrity and automatic restoration is used at the primary server, data on a backup server wouldbe clean.
- The same is true for RAIDZ implementations. While RAIDZ provides disk redundancy, copies=2 would be required to provide for automatic file restoration.

Expanding a VDEV:

Spare drives can be added to RAID VDEV's but they can not (currently) be used to expand the VDEV. However, Zmirrors or RAID-ZX arrays can be “upgraded” for size by failing a drive and replacing each of the array's drives, one-by-one, with larger drives. The feature to support this is “autoexpand” and it's on by default. However, it should be noted that significant RISK is involved in failing, replacing, and resilvering numerous drives, especially if they are old. Before beginning such a process, insuring the server's backup is up-to-date is highly recommended.

→ Source Code