ZFS

O ZFS é um sistema de arquivos e gerenciador de volumes lógicos combinados projetado pela Sun Microsystems. Os recursos do ZFS incluem proteção contra corrupção de dados, suporte para altas capacidades de armazenamento, compactação de dados eficiente, integração dos conceitos de sistema de arquivos e gerenciamento de volume, instantâneos e clones de cópia em gravação, verificação de integridade contínua e reparo automático, RAID-Z e ACLs NFSv4 nativas.

ZFS
Desenvolvedor	Oracle Corporation
Nome completo	ZFS
Lançamento	Novembro de 2005 (OpenSolaris)
Estruturas
Conteúdos de diretório	Tabela de Hash Extensível
Limites
Tamanho Máximo de arquivo	264 bytes (16 EiB)
Número máximo de arquivos	Por diretório: 248 Por sistema de arquivos: ilimitado
Tamanho máximo do nome de arquivo	255 caracteres ASCII (menor em codificações de caracteres multibyte como o Unicode)
Tamanho máximo do volume	256 quatrilhões de zebibytes (2128 bytes)
Recursos
Bifurcações	Sim (chamado Atributos estendidos)
Atributos	POSIX
Permissões de sistema de arquivos	POSIX, NFSv4 ACLs
Compressão transparente	Sim
Criptografia transparente	Sim
Armazenamento de caso único	Não
Sistemas operativos suportados	Solaris, OpenSolaris, distribuições illumos, OpenIndiana, FreeBSD, macOS Server 10.5 (suporte somente leitura), NetBSD, Linux através de módulo do kernel externo ou ZFS-FUSE, OSv
Portal das Tecnologias de informação

O nome ZFS está registrado como marca registrada da Oracle Corporation; embora tenha sido dado brevemente o nome expandido "Zettabyte File System", este já não é mais considerado um inicialismo. Originalmente, o ZFS era um software proprietário de código fechado desenvolvido internamente pela Sun como parte do Solaris, com uma equipe liderada pelo CTO da unidade de negócios de armazenamento da Sun, Jeff Bonwick. Em 2005, a maior parte do Solaris, incluindo o ZFS, foi licenciada como software de código aberto sob a Licença de Desenvolvimento e Distribuição Comum (CDDL), como o projeto OpenSolaris. O ZFS tornou-se um recurso padrão do Solaris 10 em junho de 2006.

Em 2010, a Oracle interrompeu a liberação do código-fonte para o novo desenvolvimento do OpenSolaris e do ZFS, efetivamente derivando seu desenvolvimento de código fonte fechado a partir do ramo de código fonte aberto. Em resposta, o OpenZFS foi criado como um novo projeto de desenvolvimento de código aberto, visando reunir indivíduos e empresas que usam o sistema de arquivos ZFS de forma aberta.

História

O ZFS foi projetado e implementado por uma equipe na Sun Microsystems (atual Oracle Corporation) liderada por Jeff Bonwick, Bill Moore e Matthew Ahrens. Foi anunciado em 14 de setembro de 2004, mas o desenvolvimento começou em 2001. O código-fonte do ZFS foi integrado no tronco principal do desenvolvimento do Solaris em 31 de outubro de 2005 e lançado como parte da compilação 27 do OpenSolaris em 16 de novembro de 2005. A Sun anunciou que o ZFS foi incluído na atualização 6/06 do Solaris 10 em junho de 2006, um ano após a abertura da comunidade OpenSolaris.

O nome até certo momento significava "Zettabyte File System", mas em 2006 já não era considerado uma abreviatura. Um sistema de arquivos ZFS pode armazenar até 256 quadrilhões de zettabytes (ZB).

Em setembro de 2007, a NetApp processou a Sun alegando que o ZFS infringiu algumas das patentes da NetApp do sistema de arquivos Write Anywhere File Layout. A Sun respondeu em juízo em outubro do mesmo ano, alegando o contrário. Os processos judiciais foram encerrados em 2010 com um acordo judicial não divulgado.

Recursos

Integridade de dados

Uma das principais características que distingue o ZFS de outros sistemas de arquivos é que ele foi projetado com foco na integridade dos dados, protegendo os dados do usuário no disco contra corrupção de dados silenciosa causada pela degradação de dados, surtos de energia, erros no firmware de disco, gravações fantasmas (a escrita anterior não chegou ao disco), leitura/escrita incorretas (o disco acessa o bloco errado), erros de paridade do DMA entre o conjunto de discos e a memória do servidor ou do controlador do dispositivo (uma vez que a soma de verificação valida os dados dentro do conjunto), erros do driver (dados acabam no buffer errado dentro do kernel), sobrescrita acidental, etc.

Integridade de dados do ZFS

Para o ZFS, a integridade dos dados é obtida usando uma soma de verificação baseada em Fletcher ou um hash SHA-256 em toda a árvore do sistema de arquivos. Cada bloco de dados têm o valor da soma de verificação computado e este valor é salvo no ponteiro desse bloco, e não no próprio bloco. Em seguida, o ponteiro do bloco tem o valor computado, com o valor sendo salvo no ponteiro dele. Essa soma de verificação é feita em toda a hierarquia da árvore do sistema de arquivos até chegar ao nó raiz que também é verificado, criando assim uma árvore de Merkle. A corrupção de dados em vôo ou leituras/escritas fantasmas (os dados lidos/escritos parecem ser corretamente validados, mas na verdade estão incorretos) são indetectáveis pela maioria dos sistemas de arquivos, pois eles armazenam a soma de verificação junto com os dados. O ZFS armazena a soma de verificação de cada bloco em seu ponteiro de bloco pai, com isso o pool inteiro se auto-valida.

Quando um bloco é acessado, independentemente de ser dados ou meta-dados, sua soma de verificação é calculada e comparada com o valor de soma de verificação armazenada do que "deve" ser. Se o checksum corresponder, os dados são passados pela pilha de programação para o processo que o pediu; se os valores não coincidirem, o ZFS pode corrigir os dados se o pool de armazenamento fornecer redundância de dados (como com o espelhamento interno), assumindo que a cópia dos dados não está danificada e com checksums correspondentes. É opcionalmente possível fornecer redundância adicional no pool, especificando o parâmetro copies = 2 (ou copies = 3 ou mais), o que significa que os dados serão armazenados duas vezes (ou três vezes) no disco, diminuindo de forma efetiva (ou, para copies = 3, reduzindo para um terço) a capacidade de armazenamento do disco. Além disso, alguns tipos de dados usados pelo ZFS para gerenciar o pool são armazenados várias vezes por padrão para segurança, mesmo com a configuração padrão copies = 1.

Se outras cópias dos dados danificados existem ou podem ser reconstruídas a partir de checksums e bits de paridade, o ZFS usará uma cópia dos dados (ou recriá-lo através de um mecanismo de recuperação RAID) e recalculará a soma de verificação, idealmente resultando na reprodução do valor inicialmente esperado. Se os dados passarem nessa verificação de integridade, o sistema pode substituir todas as cópias com defeito pelas cópias com dados corretos e a redundância será restaurada.

RAID

ZFS e RAID de hardware

Se os discos estiverem conectados a um controlador RAID, é mais eficiente configurá-lo como um adaptador de host em modo JBOD (ou seja, desativar a função RAID). Se uma placa de RAID de hardware for usada, o ZFS sempre detecta toda a corrupção de dados, mas nem sempre pode reparar a corrupção de dados porque a placa de RAID de hardware irá interferir. Portanto, a recomendação é não usar uma placa de RAID de hardware, ou colocar uma placa de RAID de hardware no modo JBOD/IT. Para que o ZFS possa garantir a integridade dos dados, ele precisa ter acesso a um conjunto RAID (para que todos os dados sejam copiados para pelo menos dois discos), ou se um único disco é usado, o ZFS precisa ativar a redundância (cópias) que duplica os dados na mesma unidade lógica. O uso de cópias do ZFS é um bom recurso para ser usado em notebooks e computadores de mesa, uma vez que os discos são grandes e, pelo menos, fornece alguma redundância limitada com apenas uma única unidade.

Existem várias razões para o porquê é melhor confiar exclusivamente no ZFS usando vários discos independentes e RAID-Z ou espelhamento.

Ao usar RAID de hardware, o controlador geralmente adiciona dados dependentes do controlador às unidades que impedem o software de RAID de acessar os dados do usuário. Embora seja possível ler os dados com um controlador de RAID de hardware compatível, isso causa inconveniência aos consumidores, porque um controlador compatível usualmente não está prontamente disponível. Usando a combinação JBOD/RAID-Z, qualquer controlador de disco pode ser usado para retomar a operação após uma falha do controlador.

Observe que o RAID de hardware configurado como JBOD ainda pode separar unidades que não respondem em tempo (como já foi visto com muitos discos rígidos de classe de consumidor de alta eficiência energética), e, nesse caso, pode exigir o uso de discos com suporte a TLER/CCTL/ERC (error recovery control) para evitar o abandono da unidade.

RAID de software usando o ZFS

O ZFS oferece software RAID através de seus esquemas de organização: RAID-Z e espelhamento.

RAID-Z é um esquema de distribuição de dados/paridade como o RAID-5, mas usa comprimento de stripe dinâmico: cada bloco tem seu próprio stripe de RAID, independentemente do tamanho do bloco, resultando em cada gravação RAID-Z sendo uma gravação no stripe inteiro. Isso, quando combinado com a semântica transacional de cópia-em-gravação do ZFS, elimina o erro de buraco de escrita (do inglês: write hole error), que acontece se os dados de paridade não corresponderem mais aos dados do disco caso aconteça um erro de escrita devido à não atomicidade do processo de escrita. RAID-Z também é mais rápido do que o RAID-5 tradicional porque não precisa executar a seqüência usual de leitura-modificação-gravação.

Como todos os stripes são de tamanhos diferentes, a reconstrução do RAID-Z deve percorrer os metadados do sistema de arquivos para determinar a geometria real do RAID-Z. Isso seria impossível se o sistema de arquivos e o arranjo do RAID fossem produtos separados, enquanto se torna viável quando há uma visão integrada da estrutura lógica e física dos dados. Ao percorrer os metadados, o ZFS pode validar cada bloco em relação à sua soma de verificação de 256 bits, enquanto os produtos de RAID tradicionais normalmente não podem fazer isso.

Além de lidar com falhas de disco inteiro, o RAID-Z também pode detectar e corrigir a corrupção silenciosa de dados, oferecendo "dados que se auto-curam": Ao ler um bloco RAID-Z, o ZFS o compara com a soma de verificação dele e, se os discos de dados não retornarem a resposta correta, o ZFS lê a paridade e depois descobre qual disco retornou dados incorretos. Em seguida, ele repara os dados danificados e retorna os dados corrigidos para o solicitante.

O RAID-Z não requer nenhum hardware especial: não precisa de NVRAM para confiabilidade e não precisa de buffer de gravação para ter bom desempenho. Com o RAID-Z, o ZFS fornece um armazenamento rápido e confiável usando discos de classe de consumidor baratos.

Existem três modos de RAID-Z diferentes: RAID-Z1 (similar ao RAID-5, permite que um disco falhe), RAID-Z2 (similar ao RAID-6, permite que dois discos falhem), e RAID-Z3 (Também referido como RAID-7, permite que três discos falhem). A necessidade do RAID-Z3 surgiu recentemente porque as configurações RAID com futuros discos (por exemplo: 6–10 TB) podem demorar muito para reparar, o pior caso sendo semanas. Durante essas semanas, o restante dos discos no RAID são mais estressados devido ao processo de reparo intensivo adicional e, posteriormente, podem falhar também. Ao usar o RAID-Z3, o risco envolvido com a substituição do disco é reduzido.

Espelhamento, a outra opção ZFS RAID, é essencialmente o mesmo que o RAID-1, permitindo que qualquer número de discos seja espelhado. Como o RAID 1, ele também permite velocidades de leitura e reconstrução mais rápidas, pois todas as unidades podem ser usadas simultaneamente e os dados de paridade não são calculados separadamente, e os vdevs espelhados podem ser divididos para criar cópias idênticas do pool.

Reconstrução e limpeza

O ZFS não possui ferramentas equivalentes ao fsck (a ferramenta de verificação e reparo de dados de sistemas de arquivos padrão do Unix e do Linux). Em vez disso, o ZFS possui uma função de limpeza integrada (o comando zpool scrub) que examina regularmente todos os dados e repara a corrupção silenciosa e outros problemas. Algumas diferenças são:

• O fsck deve ser executado em um sistema de arquivos desligado, o que significa que o sistema de arquivos deve estar desmontado e não é utilizável durante a reparação, enquanto o scrub foi projetado para ser usado em um sistema de arquivos montado e ligado, e o sistema de arquivos ZFS não precisa ser desligado.
• O fsck geralmente só verifica metadados (como o journal) mas nunca verifica os dados em si. Isso significa que, após rodar o fsck, os dados podem ainda não corresponder aos dados originais armazenados.
• O fsck nem sempre pode validar e reparar dados quando as somas de verificação são armazenados junto com os dados (sempre é o caso de muitos sistemas de arquivos), porque as somas de verificação também podem estar corrompidas ou ilegíveis. O ZFS sempre armazena as somas de verificação separadamente dos dados que verificam, melhorando a confiabilidade e a habilidade do scrub para reparar o volume. O ZFS também armazena várias cópias dos dados – metadados em particular podem ter mais de 4 ou 6 cópias (múltiplas cópias por disco e vários espelhos de disco por volume), melhorando significativamente a capacidade do scrub para detectar e reparar danos extensivos ao volume, em comparação com fsck.
• O scrub verifica tudo, incluindo metadados e dados. O efeito pode ser observado comparando os tempos do fsck e do scrub – às vezes, um fsck em um arranjo RAID grande termina em alguns minutos, o que significa que apenas os metadados foram verificados. A limpeza de todos os metadados e dados em um arranjo RAID grande leva muitas horas, o que é exatamente o que o scrub faz.

A recomendação oficial da Sun/Oracle é usar o scrub uma vez por mês em discos de classe empresarial, e uma vez por semana em discos de classe de consumidor.

Capacidade

O ZFS é um sistema de arquivos de 128 bits, portanto ele pode endereçar a 1,84 × 10¹⁹ vezes mais dados do que sistemas de 64 bits, como o Btrfs. Os limites máximos do ZFS são projetados para ser tão grandes que nunca devem ser encontrados na prática. Por exemplo, preencher completamente um único zpool com 2¹²⁸ bits de dados exigiria 10²⁴ unidades de disco rígido de 3 TB.

Os limites teóricos no ZFS são:

• 2⁴⁸: número de entradas em qualquer diretório individual
• 16 exbibytes (2⁶⁴ bytes): tamanho máximo de um único arquivo
• 16 exbibytes: tamanho máximo de qualquer atributo
• 256 quatrilhões de zebibytes (2¹²⁸ bytes): tamanho máximo de qualquer zpool
• 2⁵⁶: número de atributos de um arquivo (atualmente limitado a 2⁴⁸ pelo número de arquivos em um diretório)
• 2⁶⁴: número de dispositivos em qualquer zpool
• 2⁶⁴: número de zpools em um sistema
• 2⁶⁴: número de sistemas de arquivos em um zpool

Criptografia

Com o Oracle Solaris, o recurso de criptografia no ZFS está incorporado na pipeline de E/S. Durante as gravações, um bloco pode ser comprimido, criptografado, verificado e depois deduplicado, nessa ordem. A política de criptografia é definida no nível do conjunto de dados quando esses conjuntos de dados (sistemas de arquivos ou ZVOLs) são criados. As chaves fornecidas pelo usuário/administrador podem ser alteradas a qualquer momento sem desligar o sistema de arquivos. O comportamento padrão é que a chave seja herdada por qualquer conjunto de dados filho. As chaves de criptografia de dados são geradas aleatoriamente na hora da criação do conjunto de dados. Somente conjuntos de dados descendentes (instantâneos e clones) compartilham chaves de criptografia de dados. É fornecido um comando para trocar a chave de criptografia de dados na hora da criação do clone, ou a qualquer momento — isso não recriptografa os dados já existentes, porque nesses dados é usado um mecanismo de criptografia de chave mestra.

Outros recursos

Tanques de armazenamento

Ao contrário dos sistemas de arquivos tradicionais que residem em dispositivos únicos e, portanto, exigem que um gerenciador de volume lógico seja usado para poder usar mais de um dispositivo, os sistemas de arquivos ZFS são criados no topo de tanques de armazenamentos virtuais chamados zpools. Um zpool é construído de dispositivos virtuais (vdevs), eles próprios sendo construídos com dispositivos de bloco: arquivos, partições de disco rígido ou unidades inteiras, sendo este o uso recomendado. Os dispositivos de bloco dentro de um vdev podem ser configurados de maneiras diferentes, dependendo das necessidades e do espaço disponível: não redundante (semelhante ao RAID 0), como um espelho (RAID 1) de dois ou mais dispositivos, como um grupo RAID-Z de três ou mais dispositivos, ou como um grupo RAID-Z2 (semelhante ao RAID-6) de quatro ou mais dispositivos. Em julho de 2009, o RAID-Z3 de paridade tripla foi adicionado ao OpenSolaris. RAID-Z é uma tecnologia de proteção de dados oferecida pelo ZFS, a fim de reduzir a sobrecarga do bloco na hora do espelhamento.

Assim, um zpool (tanque de armazenamento ZFS) é vagamente parecido com a memória RAM de um computador. A capacidade total da memória RAM depende do número de pentes de memória RAM e do tamanho de cada pente. Da mesma forma, um zpool consiste em um ou mais vdevs. Cada vdev pode ser visto como um grupo de discos rígidos (ou partições, arquivos, etc.). Cada vdev deve ter redundância, caso contrário, se um vdev for perdido, então o zpool inteiro será perdido. Assim, cada vdev deve ser configurado como RAID-Z1, RAID-Z2, espelho, etc. Não é possível alterar o número de unidades em um vdev existente (o recurso de reescrita do ponteiro de bloco permitirá isso e também permite a desfragmentação), mas sempre é possível aumentar a capacidade de armazenamento adicionando um novo vdev a um zpool. É possível trocar uma unidade por uma maior e reconstruir o zpool. Se este procedimento for repetido para cada disco em um vdev, o zpool aumentará em capacidade quando o último dispositivo for sincronizado. Um vdev terá a mesma capacidade de base que o menor dispositivo do grupo. Por exemplo, um vdev composto por três unidades de 500 GB e uma unidade de 700 GB, terá uma capacidade de 4 × 500 GB.

Além disso, as zpools podem ter unidades de reserva ligadas para substituir as unidades que falharem. Na hora do espelhamento, os dispositivos de bloco podem ser agrupados de acordo com o chassi físico, de modo que o sistema de arquivos possa continuar funcionando em caso de falha de um chassi inteiro.

A composição do pool de armazenamento não se limita a dispositivos semelhantes, mas podem consistir em coleções de dispositivos heterogêneas, pois o ZFS pode combiná-los de forma transparente, distribuindo espaço para diversos sistemas de arquivos conforme necessário. Dispositivos de armazenamento podem ser adicionados de forma arbitrária aos pools existentes para expandir seu tamanho.

A capacidade de armazenamento de todos os vdevs está disponível para todas as instâncias do sistema de arquivos no zpool. Uma cota pode ser definida para limitar a quantidade de espaço que uma instância do sistema de arquivos pode ocupar, e uma reserva pode ser configurada para garantir que o espaço estará disponível para uma instância do sistema de arquivos.

Modelo transacional de cópia em gravação

O ZFS usa um modelo de objeto transacional de cópia em gravação. Todos os ponteiros de bloco dentro do sistema de arquivos contêm uma soma de verificação de 256 bits ou uma função de hash criptográfico de 256 bits (atualmente uma escolha entre Fletcher-2, Fletcher-4 ou SHA-256 ) do bloco de destino, que é verificado quando o bloco é lido. Blocos contendo dados ativos nunca são sobrescritos no lugar; em vez disso, um novo bloco é alocado, os dados modificados são escritos nele, então quaisquer blocos de metadados referentes ao mesmo são similarmente lidos, realocados e escritos. Para reduzir a sobrecarga deste processo, múltiplas atualizações são agrupadas em grupos transacionais, e o cache de escrita ZIL (log de intenção) é usado quando uma semântica de gravação síncrona é necessária. Os blocos são organizados em uma árvore, assim como suas somas de verificação (veja esquema de assinatura de Merkle).

Instantâneos e clones

Uma vantagem do sistema de cópia em gravação é que, quando o ZFS escreve novos dados, os blocos contendo os dados antigos podem ser mantidos, permitindo que uma versão instantânea do sistema de arquivos seja mantida. Os instantâneos do ZFS são consistentes (eles refletem todos os dados como existiram em um único ponto no tempo) e podem ser criados de forma extremamente rapida, já que todos os dados que compõem o instantâneo já estão armazenados, com todo o pool de armazenamento muitas vezes capturado várias vezes por hora. Eles também são eficientes em termos de espaço, pois todos os dados inalterados são compartilhados entre o sistema de arquivos e seus instantâneos. Os instantâneos são inerentemente somente leitura, garantindo que não serão modificados após a criação, embora não devam ser usados como um único meio de backup. Instantâneos inteiros podem ser restaurados e também arquivos e diretórios dentro de instantâneos.^{[carece de fontes]}

Instantâneos graváveis ("clones") também podem ser criados, resultando em dois sistemas de arquivos independentes que compartilham um conjunto de blocos. À medida que as mudanças são feitas em qualquer um dos clones de sistemas de arquivos, novos blocos de dados são criados para refletir essas alterações, mas todos os blocos inalterados continuam a ser compartilhados, independentemente da quantidade de clones existentes. Esta é uma implementação do princípio copia em gravação.^{[carece de fontes]}

Enviando e recebendo instantâneos

Os sistemas de arquivos ZFS podem ser movidos para outros pools, também em hosts remotos através da rede, pois o comando send cria uma representação de fluxo do estado do sistema de arquivos. Esse fluxo pode descrever o conteúdo completo do sistema de arquivos em um instantâneo, ou pode ser um delta entre instantâneos. A computação do fluxo delta é muito eficiente e seu tamanho depende do número de blocos alterados entre os instantâneos. Isso fornece uma estratégia eficiente, por exemplo, para sincronizar backups externos ou espelhos de alta disponibilidade de um pool.^{[carece de fontes]}

Striping dinâmico

O striping dinâmico em todos os dispositivos para maximizar largura de banda significa que quando dispositivos adicionais são adicionados ao zpool, a largura do stripe se expande automaticamente para incluí-los; assim, todos os discos em um pool são usados, o que equilibra a carga de escrita em todos eles.

Blocos de tamanho variável

O ZFS usa blocos de tamanho variável, com 128 KB como o tamanho padrão. Os recursos disponíveis permitem que o administrador ajuste o tamanho de bloco máximo que é usado, uma vez que determinadas cargas de trabalho não têm bom desempenho com blocos grandes. Se a compressão de dados estiver ativada, são usados tamanhos de blocos variáveis. Se um bloco pode ser comprimido para se ajustar a um tamanho de bloco menor, o tamanho menor é usado no disco para usar menos armazenamento e melhorar a taxa de transferência de E/S (embora ao custo de uso da CPU aumentada para as operações de compressão e descompressão).

Criação de sistema de arquivos leve

No ZFS, a manipulação do sistema de arquivos dentro de um pool de armazenamento é mais fácil do que a manipulação de volume dentro de um sistema de arquivos tradicional; O tempo e o esforço necessários para criar ou expandir um sistema de arquivos ZFS estão mais próximos do de criar um novo diretório do que a manipulação de volume em outros sistemas.

Endianness adaptativa

Pools e seus sistemas de arquivos ZFS associados podem ser movidos entre diferentes arquiteturas de plataforma, incluindo sistemas que implementam diferentes ordens de bytes. O formato do ponteiro do bloco do ZFS armazena metadados do sistema de arquivos de maneira adaptativa; blocos de metadados individuais são escritos com a ordem do byte nativo do sistema que escreve o bloco. Quando fazendo a leitura, se o endianness armazenado não coincide com a endianness do sistema, o metadado têm a ordem dos bytes trocada na memória.^{[carece de fontes]}

Isso não afeta os dados armazenados; como é usual nos sistemas POSIX, os arquivos aparecem em aplicativos como matrizes simples de bytes, de modo que os aplicativos criando e lendo dados continuam a ser responsáveis por fazê-lo de forma independente da endianness do sistema subjacente.^{[carece de fontes]}

Desduplicação

A capacidade de desduplicação de dados foi adicionada ao repositório de fontes do ZFS no final de outubro de 2009, e os pacotes de desenvolvimento do ZFS do OpenSolaris relevantes estão disponíveis desde 3 de dezembro de 2009 (compilação 128).

O uso efetivo da desduplicação pode exigir grande capacidade de RAM; As recomendações variam entre 1 e 5 GB de RAM para cada TB de armazenamento. A memória física insuficiente ou a falta de cache do ZFS podem resultar em uma thrashing de memória virtual ao usar a desduplicação, o que pode diminuir o desempenho ou resultar na completa inanição de memória. Unidades de estado sólido (SSDs) podem ser usadas para armazenar tabelas de desduplicação, melhorando assim o desempenho da desduplicação.

Outros fornecedores de armazenamento usam versões modificadas do ZFS para obter taxas de compressão de dados muito altas. Dois exemplos em 2012 foram GreenBytes e Tegile. Em maio de 2014, a Oracle comprou a GreenBytes por causa da sua tecnologia de duplicação e replicação do ZFS.

Plataformas

Solaris

Solaris 10 update 2 e superior

O ZFS faz parte do próprio sistema operacional Solaris da Sun e, portanto, está disponível nos sistemas SPARC e x86.

Solaris 11

Depois do lançamento do Solaris 11 Express feito pela Oracle, a consolidação OS/Net (o código principal do SO) se tornou proprietário e de código fonte fechado, e várias melhorias e implementações do ZFS no Solaris (como a encriptação) não são compatíveis com outras implementações não-proprietárias que usam versões anteriores do ZFS.

Ao criar um novo pool do ZFS, para manter a capacidade de usar o acesso ao pool de outras distribuições baseadas em Solaris não proprietárias, recomenda-se atualizar para o Solaris 11 Express a partir do OpenSolaris (snv_134b) e, assim, permanecer no ZFS versão 28.

OpenSolaris

OpenSolaris 2008.05, 2008.11 e 2009.06 usam o ZFS como seu sistema de arquivos padrão. Existem mais de uma dúzia de distribuições de terceiros, das quais cerca de uma dúzia são mencionadas aqui. (OpenIndiana e illumos são duas novas distribuições não incluídas na página de referência de distribuição do OpenSolaris).

OpenIndiana

OpenIndiana usa OpenZFS com flags de recursos como implementado no Illumos. ZFS versão 28 foi usado na versão 151a3.

Ao atualizar do OpenSolaris snv_134 para o OpenIndiana e o Solaris 11 Express, também é possível atualizar e inicializar separadamente o Solaris 11 Express no mesmo pool do ZFS, mas não se deve instalar o Solaris 11 Express primeiro devido às incompatibilidades do ZFS introduzidas pela Oracle após a versão 28 do ZFS.

BSD

macOS

OpenZFS no OSX (abreviado para O3X) é uma implementação do ZFS para macOS. O3X está em desenvolvimento ativo, com estreita relação com o ZFS no Linux e a implementação do ZFS no Illumos, mantendo a compatibilidade de bandeira de recursos com o ZFS no Linux. O3X implementa a zpool versão 5000 e inclui o Solaris Porting Layer (SPL) originalmente criado para MacZFS, que foi aprimorado para incluir uma camada de gerenciamento de memória com base nos alocadores do illumos kmem e vmem. O3X é totalmente funcional, suportando a compressão LZ4, desduplicação, ARC, L2ARC e SLOG.

O MacZFS é um software livre que oferece suporte para o ZFS no macOS. O ramo estável legado fornece o pool de ZFS até versão 8 e o sistema de arquivos ZFS versão 2. O ramo de desenvolvimento, baseado em ZFS no Linux e OpenZFS, fornece funcionalidade ZFS atualizada, como a zpool ZFS versão 5000 e os sinalizadores de recursos.

Uma implementação proprietária do ZFS (Zevo) estava disponível sem custo da GreenBytes, Inc., implementando sistema de arquivos ZFS até a versão 5 e o pool ZFS versão 28. O Zevo ofereceu um conjunto de recursos limitado do ZFS, com desenvolvimento comercial adicional pendente; foi vendido à Oracle em 2014, com planos futuros desconhecidos.

DragonFly BSD

Edward O'Callaghan iniciou um port inicial do ZFS para o DragonFly BSD.

NetBSD

O port do ZFS no NetBSD foi iniciado como parte do Google Summer of Code 2007 e em agosto de 2009, o código foi incorporado na árvore de código fonte do NetBSD.

FreeBSD

Paweł Jakub Dawidek portou o ZFS para o FreeBSD, e ele passou a fazer parte do FreeBSD desde a versão 7.0. Isso inclui zfsboot, que permite inicializar o FreeBSD diretamente a partir de um volume ZFS.

A implementação do ZFS no FreeBSD é totalmente funcional; os únicos recursos faltantes são o servidor kernel CIFS e iSCSI, mas esses últimos podem ser adicionados usando pacotes disponíveis externamente. O Samba pode ser usado para fornecer um servidor CIFS em espaço do usuário.

FreeBSD 7-STABLE (onde as atualizações da série de versões 7.x são feitas) usa o zpool versão 6.

O FreeBSD 8 inclui uma implementação muito atualizada do ZFS e o zpool versão 13 é suportado. O suporte ao zpool versão 14 foi adicionado ao ramo 8-STABLE em 11 de janeiro de 2010 e está incluído no FreeBSD versão 8.1. O zpool versão 15 é suportado na versão 8.2. O ramo 8-STABLE ganhou suporte para zpool versão v28 e o ZFS versão 5 no início de junho de 2011. Essas mudanças foram lançadas em meados de abril de 2012 com o FreeBSD 8.3.

FreeBSD 9.0-RELEASE usa o Pool ZFS versão 28.

FreeBSD 9.2-RELEASE é a primeira versão do FreeBSD que usa a nova implementação baseada em "flags de recursos" na Pool versão 5000.

MidnightBSD

MidnightBSD, um sistema operacional de desktop derivado do FreeBSD, suporta o pool de armazenamento ZFS versão 6 a partir de 0.3-RELEASE. Isso foi derivado do código incluído no FreeBSD 7.0-RELEASE. Uma atualização para o pool de armazenamento 28 está em progresso em 0.4-CURRENT e é baseado no código fonte do FreeBSD 9.1-RELEASE.

TrueOS

TrueOS (anteriormente conhecido como PC-BSD) é uma distribuição orientada para desktop do FreeBSD, que herda o suporte ao ZFS.

FreeNAS

FreeNAS, uma distribuição de código aberto baseada no FreeBSD para dispositivos dedicados ao armazenamento de dados em rede, tem o mesmo suporte do ZFS que o FreeBSD e o PC-BSD.

ZFS Guru

ZFS Guru, uma distribuição de código aberto baseada no FreeBSD para dispositivos dedicados ao armazenamento de dados em rede.

pfSense e PCBSD

pfSense, distribuição para roteador baseado em BSD de código aberto e PCBSD, uma distribuição de desktop baseada em BSD, ambos suportam o ZFS (pfSense na versão 2.4).

NAS4Free

NAS4Free, uma distribuição de código aberto baseada no FreeBSD para dispositivos dedicados ao armazenamento de dados em rede, tem o mesmo suporte a ZFS que o FreeBSD, no pool de armazenamento do ZFS versão 5000. Este projeto é uma continuação do projeto da série FreeNAS 7.

Debian GNU/kFreeBSD

Sendo baseado no kernel do FreeBSD, o Debian GNU/kFreeBSD possui suporte para o ZFS no kernel. No entanto, são necessárias ferramentas de modo usuário adicionais, enquanto é possível ter o ZFS como sistema de arquivos no diretório raiz (/) ou no diretório /boot, nesse caso, a configuração do gerenciador de inicialização GRUB requerida é realizada pelo instalador do Debian desde o lançamento do Debian Wheezy.

Desde 31 de janeiro de 2013, a versão do ZPool disponível é a 14 para o Debian Squeeze e a 28 para o Debian Wheezy.

Linux

Embora o sistema de arquivos ZFS ofereça suporte a sistemas operacionais baseados em Linux, surgem dificuldades para os mantenedores de distribuições Linux que desejam fornecer suporte nativo para o ZFS em seus produtos devido a possíveis incompatibilidades legais entre a licença CDDL usada pelo código ZFS e a licença GPL usada pelo núcleo Linux. Para habilitar o suporte ao ZFS no Linux, um módulo de kernel carregável que contenha o código ZFS licenciado com CDDL deve ser compilado e carregado no kernel. De acordo com a Free Software Foundation, a redação da licença GPL proíbe legalmente a redistribuição do produto resultante como um trabalho derivado, embora este ponto de vista tenha causado controvérsia.

Ver também

• APFS, sistema de arquivos baseado em cópia em gravação da Apple para macOS, iOS, tvOS e watchOS
• Btrfs, sistema de arquivos semelhante para Linux
• HAMMER, sistema de arquivos semelhante para DragonFly BSD
• LVM - Logical Volume Manager (para Linux), suporta instantâneos (snapshots)
• NILFS – um sistema de arquivos para o Linux com somas de verificação (mas não faz limpeza de dados), também suporta instantâneos
• ReFS – sistema de arquivos baseado em cópia em gravação da Microsoft para Windows Server 2012, que têm suporte à resiliência a danos
• Reiser4

Ligações externas

• «Projeto OpenZFS» (em inglês) 
• «Página oficial do ZFS on Linux» (em inglês)