BTRFS vs Openzfs
Mecanismo de cópia sobre gravação (vaca)
Ambos os sistemas de arquivos usam o mecanismo de cópia sobre gravação. Isso significa que, se você estiver tentando modificar um arquivo, nenhum dos sistemas de arquivos tentará substituir os dados existentes no disco com os dados mais recentes. Em vez disso, os dados mais recentes são escritos em outro lugar e, uma vez concluído a operação de gravação, o sistema de arquivos simplesmente aponta para os blocos de dados mais recentes e os blocos antigos são reciclados ao longo do tempo. Esse mecanismo permite que os sistemas de arquivos tenham recursos como instantâneos e clonagem.
A vaca também impede casos de borda como gravações parciais, que podem acontecer devido ao pânico do kernel ou falha de energia e potencialmente corrompem todo o seu sistema de arquivos inteiro. Com a vaca no lugar, uma redação aconteceu ou não aconteceu, não há não.
Pooling e Raid
Ambos os sistemas de arquivos pretendem eliminar a necessidade de um gerente de volume, RAID e outras abstrações que ficam entre o sistema de arquivos e os discos. Isso é mais robusto e confiável do que ter um controlador de invasão de hardware, simplesmente porque elimina um único ponto de falha - o próprio controlador de ataque.
Openzfs oferece um mecanismo de ataque estável, confiável e fácil de usar. Você pode refletir entre as unidades, use Raidz1, que espalha seus dados em 3 ou mais disco com um bloco de paridade. Para que ele possa suportar a falha do disco Upton 1 por vdev. Da mesma forma, Raidz2 pode usar 4 ou mais discos e suportar até 2 discos falhando e, da mesma forma, temos Raidz3.
Os BTRFs também têm esses recursos implementados, a diferença é simplesmente que os chama de ataque, em vez de Raidz e assim por diante. Algumas configurações mais complicadas de matriz de ataque como RAID56 são de buggy e não são adequadas para uso, no momento da redação deste artigo.
Licenciamento
Uma das razões pelas quais o OpenZFS chegou tão tarde no ecossistema GNU/Linux é por causa de sua incompatibilidade de licença com GNU GPL. Sem entrar em muitos detalhes, o BTRFS está sob o GPL, que permite que os usuários pegem o código -fonte e o modifiquem, mas as modificações também devem ser publicadas no GPL e manter o código aberto.
O OpenZFS, por outro lado, é licenciado no CDDL, que é muito mais permissivo e permite que os usuários modifiquem e distribuam o código com um maior grau de liberdade.
Comunidades e empresas por trás delas
Openzfs tem uma comunidade enorme por trás disso. Comunidade FreeBSD, Comunidade Illumos e muitos outros projetos de código aberto dependem do OpenZFs e, portanto, contribuem de volta para o sistema de arquivos. Ele cresceu várias vezes em termos de base de código, base de usuários, recursos e flexibilidade desde o início. Empresas como Delphix, IXSystems, Joyent e muitas mais confiam nele e fazem com que seus desenvolvedores trabalhem porque é um componente central de seus negócios. Muitas outras organizações podem estar usando o OpenZFs sem o nosso conhecimento, graças à licença CDDL, elas não precisam sair e dizer que eles usam.
BTRFS tinha Red Hat como um dos principais administradores de sua comunidade. No entanto, isso recebeu um grande golpe há um tempo quando o Red Hat depreciou o sistema de arquivos, isso significa que você não o verá em nenhum futuro Rhel e a empresa não fornecerá suporte comercial para ele. SUSE, no entanto, chegou ao ponto de torná -lo seu padrão e ainda é uma comunidade próspera por trás do sistema de arquivos com contribuições do Facebook, Intel e outros gorilas de 800 libras do Vale do Silício.
Confiabilidade
ZFS era projetado para ser confiável logo desde o início. As pessoas têm zpools que remontam ao início dos anos 2000 que ainda são utilizáveis e garantidos para não retornar dados errôneos silenciosamente. Sim, houve alguns snafus com arquivos desaparecendo no OpenZFs no Linux, mas, dada a longa história, o histórico foi surpreendente limpo.
BTRFS, por outro lado, teve problemas desde o início. Com interfaces de buggy para perda de dados e corrupção de arquivo direto. Mesmo agora, é um estoque de riso na comunidade. Faça disso o que você vai.
Oses suportados
O BTRFS teve sua origem tem um sistema de arquivos para Linux, enquanto o ZFS foi concebido dentro do Sun, para Solaris OS. No entanto, o OpenZFS já foi portado para FreeBSD, OS X da Apple, derivados de código aberto de Solaris. Seu apoio ao Linux veio um pouco mais tarde, teria previsto, mas está aqui e as empresas dependem disso. Um projeto para fazê -lo no Microsoft Windows também está fazendo um pouco de progresso, embora ainda não esteja lá.
Conclusão: uma nota sobre monoculturas
Toda essa palestra pode convencê -lo a usar o OpenZFS para manter seus dados seguros, e esse não é um curso de ação ruim. É objetivamente melhor que os BTRFs em termos de recursos, confiabilidade, comunidade e muito mais. No entanto, a longo prazo, isso pode não ser bom para a comunidade de código aberto, em geral.
Em um post intitulado semelhante a este, o autor fala sobre o perigoso das monoculturas. Eu encorajo você a passar por este post. A essência disso é isso - As opções são importantes. Uma das maiores forças do software de código aberto (e software, em geral) é que temos várias opções para adotar. Há Apache e depois há Nginx, há BSDs e Linux, há OpenSSL e há Libressl.
Se houver uma falha fatal em qualquer uma dessas tecnologias -chave, o mundo não parará de girar. Mas com a prevalência de OpenZFs, a tecnologia de armazenamento se transformou em uma monocultura. Então, eu gostaria muito para os desenvolvedores e programadores de sistemas que estão lendo isso, adotar não o OpenZFs, mas projetos como BTRFs e Hammer.