Sun Microsystems created ZFS for the proprietary Solaris operating system. It appeared as a replacement for UFS, which was supposed to cover any needs from the file system for a long time (the very name ZFS is typical – Zettabyte File System, a hint of unattainable volumes)
After the product began to be distributed with open source under the CDDL license and the name OpenSolaris
Then Oracle bought Sun Microsystems, and the project was transferred back to the proprietary category. Before this, FreeBSD managed to attract the code; Apple had some developments; they even built the implementation into the standard distribution but abandoned it, eventually introducing their analog of AFS. At the same time, a fork appeared that turned into OpenZFS. First, those who wished to work on OpenSolaris then created OpenZFS, under which they gathered all the efforts within Illumos (a fork of OpenSolaris).
ZFS on Linux has a different story. The US Livermore National Laboratory used Luster FS as a distributed file system for supercomputers. Its peculiarity is that on each node under it, another local Ldiskfs file system is used – this is a patched Ext3, the developments of which served as the basis for Ext4. Ldiskfs had several shortcomings, and ZFS was supposed to replace this file system, so the ZFS on Linux project was born.
OpenZFS has a versioning issue. There is ZFS from Oracle, and there is OpenZFS; the latter cannot repeat the proprietary version, nor is it trivial to get its source code. Initially, both the pool and the dataset in ZFS had a version; when updating Solaris, you could raise the corresponding version. After the upgrade, the pool may not be imported in the old code at all, or it may be imported in read-only mode.
The OpenZFS project already had many implementations: FreeBSD, Linux, Solaris, macOS; it was necessary to link all the developments. For this, they came up with feature flags, the so-called. Functional flags. For example, you check the box that the pool supports LZ4 compression, and then you look at it from the code – the feature is supported / not supported (that is, is it possible to import the pool).
Each flag has a signature – is it possible to import a pool with it in read-only mode since many things are important only when data changes on media. Each implementation began to acquire its feature flags, and platforms transferred them between each other through backports.
ZFS is not included in the Linux kernel, and other filesystems in Linux come out of the box, i.e., in the core. The issue of inclusion in the kernel is a license issue; this is a complex issue. However, there is a separate kernel module it can be updated without problems, regardless of the kernel version.
Linux Has Two Mechanisms For This
- DKMS is a dynamic build from the source. We automatically set the headers needed to build the module; it arrives and is automatically assembled with the necessary parameters. In the worst case, if compatibility is not checked, DKMS will not build and report anything about it, but the risk is very small. The maintainers of distribution-specific package repositories can check package compatibility with available kernel versions.
- KMOD – the kernel module comes from the repository in binary form; a specific assembly is compatible with a certain version of the kernel ABI. There is no risk of module build issues common with DKMS, but module package maintainers should promptly provide new versions when fresh kernels become available.
The difference comes from the package: the source code as in DKMS or the binary file as in KMOD.
Also Read: What Is a Software Application And What Is It Used For
