O que realmente importa ao lidar com pools do ZFS e portabilidade de conjuntos de dados são suas versões. Você sempre pode importar um pool usando uma versão menor ou igual à que o sistema operacional suporta, e a mesma regra se aplica a conjuntos de dados (por exemplo, sistemas de arquivos, zvols e snapshots).
Portanto, se você planeja mover os pools do ZFS de alguns SOs para outros, certifique-se de selecionar a maior versão comum para pools, sistemas de arquivos e zvols que deseja compartilhar. por exemplo:
zpool create -o version=28 -O version=5 ...
Tenha também em atenção que o ramo Open Source do ZFS introduziu "sinalizadores de funcionalidades" que, quando activados, tornam os conjuntos incompatíveis com o Solaris. Eles definiram a versão do pool como 5000. Por outro lado, os flags de recursos foram projetados para permitir alguma flexibilidade ao mover um pool para um sistema operacional que não suporta alguns recursos.
Sobre as arquiteturas, os objetos do ZFS são gravados usando a ordenação nativa de bits da plataforma. Isso não é um problema, pois todas as implementações do ZFS são capazes de ler objetos big endian e little endian. O endianness é armazenado junto com todas as estruturas de dados. Não há, então, nenhum problema ao importar um pool de, digamos, x86 para SPARC e reciprocamente.
Por fim, você pode ter problemas ao lidar com pools criados em discos não inteiros. O sistema operacional de destino deve ser capaz de entender o particionamento do disco de origem. O pior cenário seria se você cria um pool com base em arquivos simples (o que não é recomendado fora do teste) e o sistema de arquivos usado não pode ser montado na plataforma de destino.