Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know that ZFS is available on variety of operating systems Solaris, Illumos, Linux, BSD etc.

Suppose I have a bunch of disks that are part of ZFS raid file system that was created on Linux, could those drives be taken out of the Linux machine and put into a machine running BSD or Illumos and just work? Are there any OS specific things that are written to ZFS file systems that would make moving a disk between different implementations of ZFS a problem?

What about if the ZFS formatted disks were moved across CPU architectures say from a machine running SPARC to x86. Would the ZFS metadata be affected by endianess of the CPU architecture?

share|improve this question

What really matters when dealing with ZFS pools and datasets portability is their versions. You can always import a pool using a version less or equal to the one your OS supports, and the same rule applies for datasets (i.e. file systems, zvols and snapshots).

So if you plan to move ZFS pools from some OSes to different ones, make sure you select the largest common version for pools, file systems and zvols you want to share. eg:

zpool create -o version=28 -O version=5 ...

Beware too that the Open Source branch of ZFS introduced "feature flags" which, when enabled, make the pools incompatible with Solaris. They set the pool version to 5000. On the other hand, feature flags were designed to allow some flexibility when moving a pool to an OS not supporting some features.

About architectures, ZFS objects are written using the native bit ordering of the platform. This is not a problem as all ZFS implementations are able to read both big endian and little endian objects. The endianness is stored along with all data structures. There is then no issue importing a pool from say x86 to SPARC and reciprocally.

Finally, you might have issues when dealing with pools built on non whole disks. The target OS must be able to understand the source disk partitioning. The worst case scenario would be if you create a pool based on plain files (which is not recommended outside testing) and the file system used cannot be mounted on the target platform.

share|improve this answer

This article titled:ZFS Portability would seem to indicate that ZFS is very portable from the different implementations. From Linux, FUSE, BSD, etc.

excerpt #1

I have found a few examples where people have migrated ZFS pools between operating systems but only as one-off experiences with their fingers firmly crossed. Here is what I discovered while moving two zpools created in FreeNAS to several other operating systems.

My zpools consist of a pair of mirrored 500GB drives named cft and a single 2TB drive named single. The first thing I learned is that you should keep careful track of your pool names because the ZFS utilities will not always recognize and import them automatically.

excerpt #2

Astonishingly, ZFS FUSE recognized the pools and automatically mounted them upon boot. The mount points changed from /mnt/cft/ and /mnt/single/ under FreeNAS to /cft and /single but simply worked.

Also quite astonishingly, this works using a Xubuntu live CD. Open a terminal, type the apt-get commands, hit enter when prompted and then start using zfs(8) and zpool(8) as you normally would.

excerpt #3

As you have probably noticed when installing FreeBSD 9.0, the installer now gives a choice of a shell and live CD. I found that the live CD and the PC-BSD command line ZFS tools behaved the same. This should be no surprise considering that they are both essentially FreeBSD 9.0. What was unexpected however was the fact that FreeBSD 9.0 did not automatically recognize the zpools for import. This was even after reformatting the single drive in case the Ubuntu ZFS FUSE tools made changes to it. The mismatch between ZFS versions may have something to do with this but it was not a problem under Ubuntu which is ZFS version 16. The leap from version 15 under FreeNAS to version 28 in FreeBSD 9.0 is probably the cause but the backwards compatibility could be slightly more elegant.

excerpt #4

I encourage you to experiment with ZFS journeys between more systems and will gladly publish your findings. The potential for universal ZFS pool portability just might take the pain out of RAID administration and broken mirror data interrogation once and for all.

share|improve this answer
The link appears to point to the wrong place, and this answer seems to deal exclusively with OS portability whereas the OP is asking about CPU architecture portability as well. – Michael Kjörling Nov 23 '13 at 22:43
@MichaelKjörling - thanks, fixed link. The 1st part of his Q seems to be exactly what the article is discussing. Are RAID members portable across ZFS implementations. Haven't seen anything about architectures, but I would assume that the implementation of ZFS insulates you from this since I would assume it's higher up on the stack. The RAID disks should be technology aware (ZFS, MDADM, etc.) and not CPU/Arch. aware. – slm Nov 23 '13 at 22:45

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.