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.
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.