ZFS otimizado com viabilidade de ambiente com pouca RAM?

Atualmente, estou configurando um servidor de arquivos e cheguei ao ponto de realmente configurar as unidades de dados. O sistema possui 4 unidades (um disco do SO, 3 discos de dados). O disco do SO está formatado como ext4 e não será adicionado ao pool do ZFS (se eu optar por executar o ZFS). Minha principal preocupação é a integridade dos dados e o risco mínimo de perda de dados (o cache da unidade é desativado no BIOS). Para isso, o ZFS parece ser o candidato perfeito, já que possui uma versão estável para Linux (correta?) E suporta duplicação de dados, pool e raidz, onde os discos rígidos não precisam ter o mesmo tamanho.

Mas aqui está meu problema. O servidor possui apenas 2 GB de RAM e isso não pode ser atualizado em um futuro próximo, e realisticamente apenas 1,5 estará acessível para o ZFS depois que eu instalar todos os outros serviços. Um máximo de 10 clientes o usarão a qualquer momento (mais como 4 em média). Isso é muito baixo para ser considerado seguro?

Pelo que entendi, o ZFS pode travar em situações de pouca RAM e levar o pool com ele. Ouvi opiniões conflitantes sobre se a troca ajudará a aliviar esse problema (eu tenho uma unidade dedicada de troca de 20 GB). Alguém experimentou perda de dados com o ZFS com pouca RAM e quais otimizações você incluiu para evitar isso?

Tendo em mente o que precede, ainda é possível executar o ZFS, embora reduza o tamanho da confirmação e reduza um pouco ou isso será muito arriscado?

Especificações do sistema: sistema operacional da unidade de troca de 2 GB de RAM e 20 GB, Debian 7, instalação mínima, com FTP e XBMC, DNLA (para dar uma idéia do requisito de RAM). Usado para servidor de armazenamento e mídia de música transmitida para outros dispositivos.

Você declara a integridade dos dados e o risco mínimo de perda de dados como principais preocupações. A execução do ZFS com apenas 2 GB de memória é arriscada e desaconselhável. Pouca memória RAM reduz o desempenho e foi a causa de vários pools desmontáveis ​​no passado. O projeto FreeNAS indica 8GiB de RAM no mínimo.

Além disso, como sua preocupação é com a perda de dados, convém usar a RAM do ECC. Como sua caixa suporta apenas 2 GiB de RAM, presumo que seja uma caixa realmente antiga que não seria uma boa opção para o ZFS.

Para responder suas perguntas:

[…] E suporta duplicação de dados

Na prática, esqueça a desduplicação quando você não tiver pelo menos 32GiB, apenas como regra geral. Você pode precisar de significativamente mais memória RAM, dependendo do tamanho do pool. Segundo, faça as contas se os custos de deduplicação + RAM forem mais baratos que um punhado de discos adicionais. Frequentemente, mais discos são a alternativa mais barata.

Isso é muito baixo para ser considerado seguro?

Sim, é muito baixo.

Pelo que entendi, o ZFS pode travar em situações de pouca RAM e levar o pool com ele.

Isso é verdade e muitas pessoas perderam suas piscinas devido à baixa RAM.

Ouvi opiniões conflitantes sobre se o swap ajudará a aliviar esse problema

Esqueça a troca, sua caixa do ZFS nunca deve usar a troca.

EDIT: Se você estiver se sentindo aventureiro e não se importa com o risco de pânico ocasional ou perda de dados, leia o guia de ajuste do ZFS e adapte as configurações mencionadas. Aqui estão as configurações de exemplo para um sistema de 768MiB de memória.

vm.kmem_size="330M"
vm.kmem_size_max="330M"
vfs.zfs.arc_max="40M"
vfs.zfs.vdev.cache.size="5M"

Caso contrário, invista cem dólares em uma faixa de memória e desfrute de um sistema estável e de alto desempenho.

Em sistemas com alta pressão de memória (linux), é realmente necessário atualizar a memória. Ainda existe um bug ( link ) em que a troca bloqueia a IO (tarefa travada no kernel), tornando-a inutilizável, a menos que seja reiniciada. Eu acredito que o vm.swappiness = X não tem efeito no zfs, portanto, limitar o arco a um determinado número pode ajudar um pouco.