Skip to content
behlendorf edited this page Aug 14, 2010 · 10 revisions

1.1 What about the “licensing” issue?

In a nutshell, the issue is that the Linux kernel which is licensed under the GNU General Public License is incompatible with ZFS which is licensed under the Sun CDDL. While both the GPL and CDDL are open source licenses their terms are such that it is impossible to simultaneously satisfy both licenses. This means that a single derived work of the Linux kernel and ZFS cannot be legally distributed.

One way to resolve this issue is to implement ZFS in user space with FUSE where it is not considered a derived work of the kernel. This approach resolves the licensing issues but it has some technical drawbacks. There is another option though. The CDDL does not restrict modification and release of the ZFS source code which is publicly available as part of OpenSolaris. The ZFS code can be modified to build as a CDDL licensed kernel module which is not distributed as part of the Linux kernel. This makes a Native ZFS on Linux implementation possible if you are willing to download and build it yourself.

1.2 Why doesn’t it build?

Building a kernel module against an arbitrary kernel version is a complicated thing to do. Every distro has their own idea of how this should be done. It depends on the base kernel version, any distro specific patches, and exactly how the kernel was configured and built. If you run in to problems here are few thing to check. If none of these things explain your problem please open up a new SPL issue or a new ZFS issue as appropriate.

  • The kernel API changes frequently and kernels newer than 2.6.34 are not yet supported.
  • Check for known SPL and ZFS build issues.
  • There is also a list of tested platforms you might find helpful.

1.3 How do I mount the file system?

You can’t… at least not today. While we have ported the majority of the ZFS code to the Linux kernel that does not yet include the ZFS posix layer. The only interface currently available from user space is the ZVOL virtual block device.

1.4 Is this useful without the ZFS posix layer?

Absolutely. While having the ZFS posix layer is ideal even without it you can take advantage of many ZFS features. For example, our focus is on integrating ZFS and Lustre so we can take advantage of ZFS’s advanced features to build a scalable multi-petabyte distributed file system with Lustre.

  • Flexible pooled storage and volume manager.
  • Copy-on-write
  • Data integrity (raidz).
  • Online repair.
  • Fast snapshots.
  • Virtual block devices.

1.5 Why should I use a 64-bit system?

1 In the Solaris kernel it is common practice to make heavy use of the virtual address space because it is designed to work well. However, in the Linux kernel most memory is addressed with a physical address and use of the virtual address space is strongly discouraged. This is particularly true on 32-bit arches where the virtual address space is limited to roughly 100MiB by default. Using the virtual address space on 64-bit Linux kernels is also discouraged. But in this case the address space is so much larger than physical memory it is not as much of an issue.

If you are bumping up against the virtual memory limit you will see this message in your system logs. You can increase the virtual address size with the boot option vmalloc=512M.

vmap allocation for size 4198400 failed: use vmalloc=<size> to increase size.

1.6 How can I help?

The most helpful thing you can do is to try ZFS for Linux on your system and report any issues. If you like what you see and would like to contribute to the project please send me an email. There are quite a few open issues on the issue tracker which need attention or if you have an idea of your own that is fine too.