Quão estável é o zfs-fuse 0.6.9 no Linux?

Quão estável é o zfs-fuse 0.6.9 no Linux?

Estou pensando em usar o ZFS para meu array NAS caseiro. Eu teria 4 HDDs no raidz em uma máquina Ubuntu Server 10.04.

Gostaria de usar o recurso de snapshot e desduplicação ao armazenar dados. Não estou muito preocupado com a velocidade, já que a máquina é acessada via rede N wireless e provavelmente esse será o gargalo.

Alguém tem alguma experiência prática com o zfs-fuse 0.6.9 nessa configuração (ou semelhante)?

Responder1

Eu tenho duas unidades de 500 GB em uma configuração de espelho zfs-fuse no meu NAS doméstico (debian lenny). Ele está funcionando há quase 6 meses e não tive problemas. Mais detalhesaquino meu blog.

Responder2

Existe agora umporta linux nativado ZFS. Só soube disso recentemente e, como tal, não tive oportunidade de testá-lo. Porém, está em desenvolvimento ativo, o que é um bom sinal. Provavelmente vale a pena tentar, desde que você não se assuste por ter que compilar o módulo e as ferramentas do kernel por conta própria.

Se você conseguir fazê-lo funcionar, sem dúvida terá um desempenho muito melhor do que o zfs-fuse.

Responder3

Eu sei que este tópico é antigo, mas as coisas mudaram bastante desde então. (Por exemplo, o estado do ZFS-FUSE e das opções no kernel, o discutível desaparecimento do Solaris "Aberto", etc.)

Primeiro de tudo, a porta do kernel do ZFS nãonecessariamentetem um desempenho muito melhor que o ZFS-FUSE "sem dúvida". Essa resposta parece ecoar o equívoco comum de que os sistemas de arquivos FUSE sempre apresentam desempenho pior que o do kernel. (Caso você ainda não saiba, resumindo: em teoria, os sistemas de arquivos do kernel têm melhor desempenho, se todo o resto for igual. Mas há muitos outros fatores que afetam o desempenho com impacto maior do que o kernel versus o espaço do usuário.) No entanto, com o ZFS-FUSE, parece, de acordo com os benchmarks, que em alguns casos é significativamente mais lento que o ZFS nativo (ou BTRFS). Para meus usos, porém, está tudo bem.

O Ubuntu agora tem um pacote "ubuntu-zfs" através de seu sistema de repositório PPA, que é apenas um belo pacote e construção automática de módulos do projeto nativo zfs-on-linux. Ele é executado no espaço do kernel e atualmente suporta uma versão zpool superior ao zfs-fuse.

Eu costumava usar o OpenSolaris em um grande servidor redundante de 20 TB e agora uso o Oracle Solaris 11 nele. Solaris tem alguns problemas e desafios significativos (especialmente se você estiver confortável com a configuração e administração do Linux em vez do UNIX antigo), e eles mudaram drasticamente muitos dos gerenciamentos de hardware e outras interfaces de configuração entre versões do sistema operacional e até mesmo atualizações, tornando-o um alvo móvel muitas vezes altamente frustrante (mesmo depois de finalmente dominar uma versão antes de atualizar para a próxima). Mas com o hardware certo (compatível) e muita paciência para mudanças, aprendizado e ajustes, pode ser uma escolha incrível em termos de sistema de arquivos.

Mais um conselho: não use o suporte CIFS integrado. Utilize o Samba. O suporte integrado está quebrado e pode nunca estar pronto para o horário nobre. A última vez que verifiquei, havia muitas instalações corporativas usando Samba, mas nenhuma usando CIFS devido a pesadelos de gerenciamento de permissões.

Eu também uso o ZFS-FUSE no Ubuntu diariamente (em uma estação de trabalho pessoal) e descobri que ele é uma solução sólida e incrível. Os únicos problemas que consigo pensar especificamente com o ZFS-FUSE são:

  1. Você não pode desativar o ZIL (cache de gravação), pelo menos não sem definir um sinalizador no código-fonte e compilar você mesmo. Aliás, desabilitar o ZIL, ao contrário de um equívoco comum, não fará com que você perca seu pool em caso de acidente. Você simplesmente perde tudo o que estava sendo escrito naquele momento. Isso não é diferente da maioria dos sistemas de arquivos. Pode não ser ideal para muitos cenários de servidor de missão crítica (nesse caso, você provavelmente deveria usar o Oracle Solaris nativo de qualquer maneira), mas geralmente é uma compensação muito válida para a maioria dos casos de uso pessoal/de estação de trabalho. Para uma configuração de pequena escala, o ZIL pode ser um enorme problema de desempenho de gravação, porque por padrão o cache é espalhado entre o próprio pool - o que pode ser bastante lento, especialmente se for uma configuração de faixa de paridade (RAIDZx). No Oracle Solaris desabilitar é fácil, acredito que seja a propriedade "sync" do pool IIRC. (Não sei se pode ser facilmente desativado na versão nativa do kernel Linux.)

  2. Também com o ZFS-FUSE, a versão do zpool não é alta o suficiente para suportar as melhores opções de recuperação de pool de versões mais recentes - portanto, se você decidir descarregar o cache de gravação para, digamos, um ou mais SSDs ou unidades RAM, tenha cuidado . (E sempre espelhe isso!) Se você perder o ZIL, é quase certo que também perderá todo o seu pool. (Isso aconteceu desastrosamente comigo no OpenSolaris.) Versões mais recentes do zpool no Oracle Solaris atenuaram esse problema. Parece que não consigo determinar se a porta Linux no nível do kernel tem essa mitigação incorporada ou não.

Além disso, você pode desconsiderar com segurança o alarme "bug ZFS ARC" com o qual o cara parecia enviar spam para discussões. Meu servidor sofre muito, assim como inúmeros servidores de produção em todo o mundo, e nunca experimentei isso.

Pessoalmente, embora eu não goste muito do Solaris, o ZFS é simplesmente incrível e, agora que dependo de seus recursos, não posso ficar sem ele. Eu uso até em notebooks Windows. (Através de uma solução de virtualização complexa, mas muito confiável, e unidades USB com velcro na tampa.)

Editar: algumas pequenas edições para maior clareza, relevância e reconhecimento das limitações de desempenho do ZFS-FUSE.

Responder4

Executei o ZFS-FUSE no Ubuntu por quase um ano sem problemas antes de migrar o pool para o OpenSolaris. Dito isto, os requisitos de memória para Dedup em um pool multi TB provavelmente excederão a memória do seu servidor Linux doméstico. O desempenho da desduplicação é terrível quando suas tabelas de desduplicação transbordam do ARC (cache de memória principal), a menos que você tenha um SSD para L2ARC para mantê-las prontamente disponíveis. Sem as tabelas de desduplicação na memória, várias operações podem se tornar incrivelmente lentas (exclusão de diretório de arquivos, exclusão de instantâneos, etc.). Os instantâneos podem funcionar sem desduplicação e quase não têm sobrecarga por conta própria; portanto, a menos que você armazene muita redundância e tenha de 8 a 16 GB de RAM e/ou um SSD para resolver o problema, eu pularia a desduplicação.

informação relacionada