ZFS para iniciantes

 (ikrima.dev)
2 pontos por GN⁺ 2023-09-06 | 1 comentários | Compartilhar no WhatsApp
  • Um guia introdutório organizado a partir de uma falha de ZFS no FreeNAS, cobrindo solução de problemas, criação de novos volumes e estratégias de backup, reunindo em um fluxo único a estrutura e os comandos necessários para começar a operar ZFS
  • O ZFS fornece ao mesmo tempo sistema de arquivos e gerenciador de volumes lógicos, tendo sido iniciado pela Sun Microsystems e usando principalmente o código do OpenZFS em Linux, FreeBSD e outros sistemas
  • A estrutura básica se divide em vdev, que agrupa discos físicos, pool, dataset, que cumpre o papel de sistema de arquivos, e volume, em forma de dispositivo de bloco; RAIDZ-1/2/3 toleram falha de 1, 2 e 3 discos, respectivamente
  • Os principais comandos usados na prática são zpool create/status/list/import/export/destroy/scrub e zfs create/mount/list/get/set/snapshot/diff/rollback/send/recv/destroy, e o uso de UUID do dispositivo é preferido para evitar problemas com mudança de nome dos dispositivos
  • Snapshots protegem de forma leve o estado de um momento específico e podem ser replicados para outro pool ou sistema com zfs send/recv, mas snapshots sozinhos dificilmente substituem backup ou DR

Conceitos básicos do ZFS

  • ZFS é um sistema de arquivos local como ext4, NTFS e exFAT, e ao mesmo tempo também exerce o papel de gerenciador de volumes lógicos como o LVM no Linux
  • Foi criado pela Sun Microsystems, e o código-fonte do ZFS era publicado sob licença open source até a aquisição da Sun pela Oracle
  • Como o código já havia sido portado para vários sistemas operacionais, o projeto OpenZFS foi criado depois disso, e esse código é usado na maioria dos sistemas da família Unix, como Linux e FreeBSD
  • O material foi organizado do ponto de vista de iniciantes para ajudar quem está tendo o primeiro contato com ZFS a entender sua estrutura e os comandos de operação

Componentes do ZFS

  • vdev é composto por um ou mais drives físicos, podendo incluir arquivos além de discos rígidos
    • Pode ser combinado em formatos como mirror ou RAIDZ
    • Há 7 tipos de vdev, incluindo tipos importantes como hot spare, L2ARC e ZIL
  • pool é composto por um ou mais vdevs, e normalmente é nele que se criam volumes ou datasets
    • Ao criar um pool com o comando zpool, os vdevs são definidos junto
    • É possível misturar vários tipos de vdev para compor o nível RAIDZ
  • dataset é o componente do ZFS que corresponde ao sistema de arquivos
    • Permite configurar acesso de usuários, quota, compressão, snapshot e mais
  • volume é parecido com dataset, mas fornece representação como dispositivo de bloco
    • Oferece apenas parte das funcionalidades de dataset
    • É útil para rodar outros sistemas de arquivos sobre o ZFS ou exportar um iSCSI extent

Tipos de RAIDZ

  • Dynamic/Simple Stripe, ou RAID0, distribui os dados sem parity, e a perda de um único dispositivo causa a perda de todos os dados
  • MIRROR, ou RAID1, espelha os discos e é usado com 2, 4 ou mais discos
  • RAIDZ-1, ou RAID5, distribui parity junto com os dados e tolera a perda de 1 drive físico antes de falhar o RAID
    • RAIDZ exige no mínimo 3 discos
  • RAIDZ-2, ou RAID6, tolera a perda de até 2 drives físicos
    • RAIDZ-2 exige no mínimo 4 discos
  • RAIDZ-3 tolera a perda de até 3 drives físicos
    • O mínimo é 4 discos, mas o ideal é não usar com menos de 5

Criação de pool e verificação de status

  • Um pool ZFS é criado no formato zpool create [pool] [devices]
    • Exemplo de pool com disco único: zpool create tank /dev/sdb
    • Exemplo de stripe com 3 discos: zpool create tank /dev/sdb /dev/sdc /dev/sdd
    • Exemplo de mirror com 2 discos: zpool create tank mirror sdb sdc
    • Exemplo de pool RAIDZ: zpool create tank raidz sdb sdc sdd
    • RAIDZ2/3 podem ser criados no formato zpool create [pool name] raidz[1,2,3] [devices]
  • Ao criar o pool, é possível definir o mount point padrão com a flag -m
    • Exemplo: zpool create tank -m /mnt/tank mirror sdb sdc
  • Nos exemplos é usado nome de dispositivo no formato /dev/sdx, mas para evitar problemas de boot causados por mudança no nome dos dispositivos, prefere-se usar UUID do dispositivo
  • zpool status é o comando básico para verificar o estado do pool
    • state mostra se o pool está online
    • status exibe informações adicionais sobre o pool
    • action mostra as ações de acompanhamento necessárias
    • scan indica o andamento do scrub ou o status do último scrub
    • errors mostra se há problemas no pool
  • zpool list mostra detalhes como tamanho do pool, alocação, espaço livre, fragmentation, capacity, dedup e health
  • zpool history mostra o histórico de comandos usados para alterar a configuração desde a criação do pool

Importar, exportar, remover e fazer scrub em pools

  • Depois de criado, um pool normalmente é importado e montado automaticamente, mas em resolução de problemas ou após reimaginar o sistema, pode ser necessário importá-lo manualmente
  • Executar zpool import sem nome de pool mostra a lista de pools disponíveis para importação
    • Se não houver pools importáveis, será exibido no pools available to import
    • Ao especificar o nome do pool, ele é importado, e o comando também faz o mount do pool
    • zpool import -a importa todos os pools disponíveis
  • Usando -R, como em zpool import -R /mnt/tank2 tank, o pool é montado em um alternate root
    • Isso não é o mount path do próprio pool, mas uma pasta root alternativa
  • zpool export [pool name] faz o oposto de import: tenta desmontar os sistemas de arquivos montados dentro do pool e depois exportá-lo
    • Se o unmount falhar, é possível forçar com -f
    • Se houver um volume ZFS em uso, a exportação falha mesmo com -f
  • zpool destroy remove o pool e seus datasets ou volumes filhos
    • Como todos os dados e snapshots também são apagados, é preciso cuidado
  • ZFS scrub verifica a integridade dos dados comparando todos os blocos do pool com os checksums conhecidos
    • Em vdevs com parity, dados corrompidos são recuperados usando os dados dos discos íntegros
    • Para manter a saúde do sistema, o scrub deve ser executado em uma agenda regular
    • Início: zpool scrub [pool]
    • Verificação de status: consultar a seção scan em zpool status
    • Interromper: zpool scrub -s [pool]

Criação de dataset e mount

  • zfs create é o comando para criar um novo filesystem ou volume, mas aqui o foco é dataset mais do que volume
  • zfs create tank/dataset1 cria dataset1 dentro de tank
    • O dataset tank é criado automaticamente quando se executa zpool create
  • zfs create -p também cria datasets pais ausentes, como o mkdir -p
    • Se o dataset pai não existir, o zfs create comum falha
  • Executar zfs mount sem argumentos mostra os sistemas de arquivos ZFS atualmente montados e seus mount points
    • Essa saída não inclui datasets filhos
  • zfs mount [pool|dataset] monta o filesystem especificado
    • zfs mount -a monta todos os filesystems
  • Um dataset filho pode ser montado mesmo sem o dataset pai
    • Nesse caso, os caminhos necessários são criados no sistema de arquivos do sistema operacional
    • Depois, ao tentar montar o dataset pai, pode ocorrer o erro directory is not empty por causa dos diretórios criados
  • zfs unmount [dataset] desmonta o dataset especificado

Consulta de datasets e configuração de propriedades

  • zfs list [dataset name] mostra informações do dataset especificado
    • Também é possível passar o mount point em vez do nome do dataset
  • Executar zfs list sem nome de dataset mostra recursivamente todos os datasets do sistema
  • Ao especificar o nome do dataset, a flag -r permite exibir recursivamente tudo abaixo dele
  • As propriedades do ZFS controlam o comportamento de filesystem, volume, snapshot e clone
    • Às vezes elas podem parecer opções de mount
  • zfs get all [dataset] mostra todas as propriedades do dataset
  • O valor de uma propriedade específica pode ser consultado com zfs get compression tank
  • Para definir propriedades, usa-se zfs set
    • Exemplo: zfs set compression=lz4 tank
    • Depois disso, zfs get compression tank permite confirmar que compression mudou para lz4

Como snapshots funcionam e como usá-los

  • snapshot salva o estado de um filesystem em um ponto específico no tempo, mas não copia os arquivos
  • O snapshot marca os dados existentes como read-only, e mesmo que novos dados sejam adicionados ao filesystem depois, os blocos de dados antigos protegidos pelo snapshot não são afetados
  • O fluxo de exemplo é o seguinte
    • Em um filesystem com os dados existentes Data A, cria-se o snapshot 1
    • Depois adiciona-se Data B e cria-se o snapshot 2
    • Depois adiciona-se Data C
    • O snapshot 1 protege Data A, e o snapshot 2 protege Data A e Data B
    • Mesmo que o snapshot 1 seja apagado, Data A continua protegido pelo snapshot 2
  • A quantidade de dados usada por snapshots é muito pequena
    • Isso ocorre porque, em vez de copiar arquivos, o sistema apenas registra o bloco de metadata de nível superior do filesystem como pertencente ao snapshot
  • Snapshots são úteis para testes de software ou para criar uma salvaguarda antes de upgrades
  • Apenas snapshots não devem ser considerados uma solução de backup ou DR

Comandos de snapshot

  • A criação de snapshot usa o formato zfs snapshot [pool/dataset@snapshot_name]
    • Exemplo: zfs snapshot tank/dataset1@snapshot1
  • A lista de snapshots pode ser vista com zfs list -t snapshot
  • Se houver vários datasets filhos, é possível criar o snapshot no dataset de topo ou usar a flag -r para criar um snapshot recursivo
    • Exemplo de snapshot comum: zfs snapshot tank@snapshot-master
    • Exemplo de snapshot recursivo: zfs snapshot -r tank@recursive
  • zfs diff [older snapshot] [newer snapshot] compara as diferenças entre snapshots
    • A saída permite verificar arquivos adicionados e caminhos modificados
  • A restauração de snapshot é feita com zfs rollback [pool/dataset@snapshot_name]
    • Ao fazer rollback, arquivos criados depois do snapshot são apagados
    • Snapshots mais novos também são apagados, e nesse caso pode ser exigido o uso da opção -r

ZFS send/recv e replicação

  • ZFS send permite enviar snapshots como um stream de dados
  • Snapshots e datasets podem ser replicados para um arquivo, outro pool ou outro sistema via SSH
  • O exemplo usa dois pools chamados tank e backup
    • O dataset tank/Movies contém 1.50G de dados
    • Antes da transferência, cria-se um snapshot com zfs snapshot tank/Movies@$(date '+%Y-%m-%d_%H-%M')
    • Em seguida, zfs send tank/Movies@2020-11-03_15-29 | zfs recv backup/Movies envia o snapshot para o pool de backup
  • Depois da transferência, zfs list mostra tanto backup/Movies quanto tank/Movies, e zfs list -t snapshot também mostra os snapshots dos dois lados
  • zfs send é um recurso que vale explorar em seus vários casos de uso e opções; combinado com RAIDZ e snapshots, pode tornar o filesystem mais robusto

Remoção de datasets e snapshots

  • Para remover um dataset, usa-se o formato zfs destroy [pool/dataset]
    • A flag -r também pode ser usada
  • Para remover um snapshot, também se usa zfs destroy [pool/dataset@snapshot_name]
    • A flag -r também pode ser usada na remoção de snapshots
  • O ZFS oferece muitos outros recursos, mas este material está mais para um ponto de partida para aprender os conceitos e comandos básicos

Materiais de referência

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-06
Comentários do Hacker News
  • Comecei a usar ZFS agora, e a curva de aprendizado é mais íngreme do que eu esperava. Seria bom ter um wrapper simples que tornasse casos de uso comuns muito fáceis
    Por exemplo, ao criar um pool, ele poderia simplesmente usar padrões sensatos como ashift=12, compressão lz4, xattr=sa, acltype=posixacl, atime=off, e a criptografia poderia ser apenas ligar/desligar em vez de várias opções
    Seria bom se ele gerasse a chave de criptografia, configurasse um serviço systemd para descriptografar o pool na inicialização e orientasse sobre backup da chave. zfs list deveria mostrar se o dataset está montado, se está criptografado e se a chave foi carregada
    Eu eliminaria datasets recursivos e, em vez de {pool}/{dataset}, usaria {pool}:{dataset} para distinguir claramente pool e dataset. Também seria bom não precisar dar nomes a pools ou snapshots manualmente, com regras como {hostname}-[A-Z], {pool name}_{datetime created} e nomes curtos numéricos atribuídos automaticamente
    Na criação de pools, não deveria ser necessário digitar IDs de discos manualmente; ele poderia criar usando /dev/sda, /dev/sdb e armazenar metadados nos discos para evitar confusão mesmo que a ordem dos drives mudasse
    O progresso deveria sempre ser mostrado com pv, e scrubs semanais, snapshots horários/diários/semanais/mensais e limpeza deveriam ser configurados automaticamente
    Ao enviar para um disco sem pool, após confirmação ele deveria criar um pool de disco único com as mesmas configurações do pool de origem, e zpool e zfs deveriam ser combinados em um único comando
    Ao enviar datasets criptografados, deveria usar --raw automaticamente; o padrão de envio deveria ser --replicate, e, se possível, usar -I. Também seria necessário não esconder o sistema de arquivos de snapshots em um diretório oculto, e sim oferecer uma forma fácil de montar e navegar por datasets de snapshots
    • Há uma mistura de sugestões razoáveis e preferências muito fortes. Entendo um padrão ashift=12 ou a sintaxe {pool}:{dataset}, mas parece difícil mudar isso agora, e algumas sugestões podem quebrar casos de uso que a pessoa não conhece
      Nomear pools pelo hostname não combina com pools SAN, que podem ser importados por vários hosts
      Scrubs semanais, snapshots periódicos e limpezas periódicas me parecem tarefas para o escalonador do sistema operacional. Combinar zpool e zfs até seria possível, mas no fim acabaria virando algo como zfs -pool XXXX, zfs -volume XXXX; não vejo por que isso seria necessário
      Datasets recursivos são de fato úteis em alguns casos. Por outro lado, concordo totalmente que zfs list deveria mostrar se está montado, se está criptografado e se a chave foi carregada
      A parte de não digitar IDs de discos é ambígua. É possível especificar por ID, WWN, rótulo, sdX e outros métodos, mas de alguma forma você ainda precisa informar quais discos quer usar
      A funcionalidade de armazenar metadados no disco para encontrá-lo mesmo após trocar a ordem já existe. Mesmo se você reconectar alguns drives em posições diferentes e importar o pool, ele os encontra
      Algumas sugestões seriam boas como padrões, mas outras parecem não considerar suficientemente padrões de uso e necessidades além das do próprio autor. ZFS atende a um público muito mais amplo
    • Criar um pool com /dev/sda, /dev/sdb e depois dizer que o ZFS se confunde, sinceramente, está mais para problema do usuário por não usar as práticas atuais do que para problema do ZFS
      No Linux já existe há bastante tempo uma referência completa como /dev/disk/by-id/ata-$manufactuer-$serial-$whatever. Ao criar pools, é esse tipo de caminho que deve ser usado
    • Muitas sugestões são fortemente opinativas, o que por si só não é ruim, mas parecem mexer em convenções existentes sem uma necessidade clara. Por exemplo, não entendo por que teria de ser {pool}:{dataset}
      Se você não quer dar nomes a snapshots manualmente, minha pequena ferramenta https://github.com/rollcat/zfs-autosnap pode servir
      Coloque zfs-autosnap snap no cron de hora em hora e zfs-autosnap gc diariamente, e ele vai girar o histórico de snapshots conforme a política de retenção
      Não é difícil usar um wrapper de comandos ZFS simples, então você pode pegar meu código e criar sua própria ferramenta
    • Li uma vez que uma das últimas tarefas de um aprendiz de ferreiro era fazer, ele mesmo, todas as ferramentas que um ferreiro de verdade usaria: bigorna, martelos, tenazes etc.
      No trabalho, também escrevi vários scripts para criar arrays ZFS de acordo com o formato de implantação previsto para cada ocasião. Eles incluíam criar volumes criptografados com LUKS para colocar zvols, padronizar regras de nomenclatura e definir padrões como ashift=12 e compressão lz4
      Isso foi muito antes de a criptografia nativa do ZFS existir, e como o método atual ainda não nos causa problemas, não atualizei os scripts para dar suporte à criptografia do ZFS
      Hoje não lembro muitas das flags, mas os scripts servem como documentação, e as outras pessoas da equipe só precisam executar make-zfs-big-mirror ou make-big-zfs-undundant-raid0
      Se algum dia eu tiver de provisionar sistemas mais de 20 vezes por ano, até isso poderá ser automatizado pelo provisionamento
    • Como outras pessoas já disseram, são propostas muito opinativas. Não há problema em ter opinião, mas muitos pontos vão de “não é o jeito com que estou acostumado no Linux” até sugestões que de fato têm problemas
      Dizer que não se deve nomear pools não faz sentido. Você não cria pools com tanta frequência; basta dar um nome
      Se você não quer nomear snapshots, pode usar httm e zfs allow. Por exemplo, httm -S . cria um snapshot como rpool/ROOT/ubuntu_tiebek@snap_2022-12-14-12:31:41_httmSnapFileMount
      zfs e zpool são ótimos comandos Unix, cada um com vários subcomandos. Acho que foi uma decisão muito inteligente dos projetistas do ZFS não criar um único comando de administração mais complexo
      Montar e explorar claramente datasets de snapshots também é fácil com zfs mount. Ainda assim, espero que acreditem que uma interface virtual estável facilita a busca por todas as versões de arquivos, e isso é muito mais difícil em btrfs e similares. httm também vale conferir
      [0]: https://kimono-koans.github.io/opinionated-guide/#dynamic-sn...

  • Há mais coisas úteis no ZFS. Vale a pena saber a diferença entre zpool-attach(8) e zpool-replace(8), e zfs list -t all -o space mostra onde o espaço está sendo usado
    Para proteger o sistema operacional antes de grandes mudanças ou upgrades, ZFS Boot Environments é o melhor recurso. Como ponto de partida, https://is.gd/BECTL pode ser útil
    zpool history poolname mostra toda a configuração do pool e o histórico de alterações. Por exemplo, mudanças como zpool create, autotrim=on, atime=off, compression=zstd e recordsize=1m ficam registradas
    Também há uma informação importante que ficou de fora do guia. Um espelho de 3 vias mantém os dados mesmo que 2 de 3 discos falhem; um espelho de 4 vias mantém mesmo que 3 de 4 falhem; e um espelho N-way preserva os dados mesmo que N-1 de N discos falhem
    Isso é útil quando os dados são o mais importante, mas não há muitos slots ou discos

    • Espelhos N-way também têm a característica de permitir que o ZFS distribua as leituras entre vários discos. Em discos giratórios, em que o número de operações de E/S era limitado, isso era bem importante

  • Há anos opero bancos de dados PostgreSQL grandes, de vários TB, sobre ZFS. Graças ao ZFS, ficou muito fácil fazer backups, criar ambientes de teste baseados em snapshots antigos e economizar disco com compressão integrada
    Se tiver interesse, você pode ler a experiência em https://lackofimagination.org/2022/04/our-experience-with-po...

  • O que mais ajudou quando comecei com ZFS foi o ZFS Handbook do FreeBSD e os textos de Aaron Toponce
    [0] https://docs.freebsd.org/en/books/handbook/zfs/
    1 https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux...

    • Gosto da documentação do FreeBSD
      Instalei FreeBSD em um HP Microserver antigo, com 1 GB de ECC RAM que estava sobrando, e também tinha cinco HDs antigos de 500 GB; seguindo o FreeBSD Handbook, configurei tudo como espelho 5x. Era minha primeira vez com FreeBSD e foi muito tranquilo

  • Recentemente, ao reconstruir boa parte da infraestrutura, principalmente servidores LAMP, decidi deixar tudo baseado em ZFS no Linux para ter replicação eficiente de backups e criptografia
    Eu já usava ZFS com rsync para backups havia muito tempo, então estava bem familiarizado, e no fim deu certo, mas fazer direito consumiu muito mais tempo do que eu esperava. Especialmente sobre bancos de dados e replicação, havia muitos conselhos errados na web
    Bancos de dados precisam, no mínimo, de ajustes básicos como alinhamento de tamanho de bloco. Para mariadb/InnoDB, o material da Let's Encrypt https://github.com/letsencrypt/openzfs-nvme-databases foi disparado o melhor. Ele explica o motivo de cada item e cita várias fontes, por isso é muito valioso
    Se você procurar mais na web, aparece um fluxo interminável de conselhos contraditórios, anedotas e mitos, acompanhados de teorias incompletas e sem base. No fim, é preciso testar por conta própria, entender o que está sendo ajustado, e também não há problema em decidir não ajustar algo
    Para replicação, eu realmente recomendo as man pages. O ZFS oferece ferramentas de replicação robustas, mas elas são tão genéricas que parecem comandos de encanamento de baixo nível do Git. Como ele não presume que você vá usar SSH, é preciso ligar as partes manualmente; e, para automatizar, também é preciso pensar nas condições de contorno, então no começo parece assustador
    Por isso todo mundo acaba indo para ferramentas como syncoid, mas havia algo terrível em scripts de replicação desse tipo. Eles não usam o modo send --replication do ZFS e, em nome de mais flexibilidade, o reimplementam de forma incompleta em Perl
    Nos primeiros testes, ao restaurar do zero, é de enlouquecer ver que todas as raízes de criptografia quebraram e que as propriedades dos datasets não foram sincronizadas automaticamente. Usando apenas a opção de replicação recursiva nativa, o ZFS cuida disso
    Se você se decidir a escrever seu próprio script, não é difícil. Basta mantê-lo simples e não enfiar um monte de coisas desnecessárias no pipeline como o syncoid faz. Em testes reais, essas coisas também podem reduzir a velocidade. Acompanhe o progresso com pv e simplesmente envie; funciona rápido
    Talvez algum dia eu publique meu script de replicação. Sinto que quase não há bons scripts de referência que cubram o básico sem reimplementar a replicação de forma bagunçada

    • Esse material menciona o ajuste de io_capacity e io_capacity_max, mas, ao clicar na documentação do MySQL e ver o papel real desses parâmetros, infelizmente eles não parecem muito úteis
      Esses valores controlam E/S em segundo plano, como a mesclagem do change buffer, e podem tirar E/S dos processos principais que de fato precisam trabalhar
      Pela minha experiência operando um banco MySQL bastante ocupado, de 120K QPS, não precisei mexer em nenhum dos dois. Se você sentir que precisa, primeiro monitore o tempo até o redo log encher e a proporção de páginas sujas no buffer pool. Provavelmente é melhor ajustar outros parâmetros
      [0] https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.ht...
    • Ao fazer ajustes básicos em bancos de dados, como alinhamento de tamanho de bloco, há um ponto inesperado a verificar. Normalmente dizem para alinhar o tamanho do registro, e na prática isso acaba levando a reduzir o tamanho de registro do filesystem ZFS que armazena os dados
      Em algum nível isso pode ser mais eficiente, mas, pela experiência, reduz bastante a taxa de compressão
      Como efeito secundário interessante, dependendo da carga de trabalho, se a largura de banda de disco for o gargalo, o throughput pode até piorar. Graças à compressão, é possível ler e escrever mais rápido do que o disco físico suportaria; se você arruina a compressão, pode prejudicar a largura de banda de leitura/escrita

  • Comecei a usar ZFS no Linux há alguns anos e, no geral, foi tudo tranquilo
    A única coisa que me surpreendeu foi que o valor padrão de volblocksize é bem ruim para a maioria das configurações RAIDZ. É preciso aumentar esse valor para não perder 50% do espaço bruto em disco
    Os textos relacionados são estes
    https://jro.io/nas/#overhead
    https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAID...
    https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i...
    Acabei até chegando a uma das planilhas sobre ZFS
    ZFS overhead calc.xlsx
    https://docs.google.com/spreadsheets/d/1tf4qx1aMJp8Lo_R6gpT6...
    RAID-Z parity cost
    https://docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-D...

    • Pessoalmente, vejo a eficiência de 50% dos vdevs espelhados como um preço justo, considerando a simplicidade e a melhora significativa de desempenho. Hoje também dá para expandir pools RAIDZ, mas ainda é muito mais complexo e o desempenho também não é tão bom

  • Quando eu era mais jovem e mais tolo, li muitos textos de entusiastas dizendo como um sistema operacional NAS open source, provavelmente FreeNAS, e o ZFS eram incríveis. Comprei no eBay um microservidor HP usado, de especificação bem baixa, e mergulhei nisso sem saber direito o que estava fazendo
    Fiz algumas perguntas nos fóruns da comunidade, mas a maioria das respostas era “você leu a documentação?” e “tem RAM suficiente?”
    A tal documentação era uma apresentação em PowerPoint de estilo difícil de ler, com um tom meio evangelizador, exigia muito conhecimento prévio e não era atualizada regularmente. A quantidade de RAM necessária também era vaga, e o foco era basicamente colocar o máximo possível
    No fim, ignorei todos os sinais de alerta sobre a tecnologia, o hype e o meu nível de conhecimento, e perdi muitos dados. Aprendi bastante

    • Fico curioso se você lembra mais ou menos há quanto tempo foi isso. O ZFS existe desde o início dos anos 2000, e acho que o FreeNAS começou em 2005
      O sistema de arquivos ficou muito mais estável, e a documentação também me parece mais clara
      Ainda assim, por ser mais poderoso e avançado do que um sistema de arquivos tradicional com journaling, como ext3, também há mais formas de dar um tiro no próprio pé

  • Para deixar mais algumas coisas registradas para depois: toda a redundância do ZFS fica na camada de vdev. Um zpool é feito de um ou mais vdevs e, em qualquer caso, se você perder um único vdev dentro de um zpool, o zpool é destruído permanentemente
    Historicamente, RAIDZ, ou seja, RAID com paridade, não podia ser expandido adicionando discos. A única forma de aumentar um RAIDZ era substituir cada disco do array, um por vez, por discos maiores, e torcer para nenhum disco falhar durante a reconstrução
    Em uma avaliação bem amadora, eu só consideraria RAIDZ em casos com muitos discos, como RAIDZ2 ou RAIDZ3. Se n<=6 e o orçamento permitir, eu usaria vários vdevs espelhados. Em ambiente de produção, seria preciso pesquisar melhor as métricas de desempenho de leitura/gravação dos vários tipos de RAID

    • Um pool espelhado geralmente é mesmo a abordagem mais segura
      Só recomendaria RAIDZ1 quando houver backup completo no mesmo local e você puder confiar bastante na própria capacidade e no monitoramento
      No meu caso, tenho um pool de discos 3x3 e envio snapshots para um destino de backup alguns Us abaixo no rack. Esse destino de backup acorda todos os dias, tem um pool de discos 3x4 e também usa RAIDZ1
      Se um disco falhar no NAS, meu plano é iniciar o backup imediatamente, receber os snapshots e então substituir o disco. Isso minimiza a chance de perder dados por uma segunda falha de disco durante o resilvering
      Dados realmente importantes, claro, também ficam fora do local

  • Estou enfrentando um problema com ZFS que não entendo. Em um determinado zpool, zpool status mostra uma lista de erros detectados, mas eles não aparecem em arquivos; aparecem sempre em snapshots, e talvez em itens hexadecimais que parecem ser snapshots excluídos
    Se eu excluo o snapshot marcado com erro e rodo zpool scrub duas vezes, o erro desaparece e o scrub também não encontra erros. zpool status nunca mostrou erro em nenhum dispositivo
    Não há erro em arquivos, não há erro em dispositivos e o scrub não detecta erros, mas, durante o uso, uma dúzia de novos “erros” por dia aparece em zpool status. Não faço ideia de como isso pode acontecer

    • Ótima pergunta. Não tenho tempo agora para procurar pessoalmente issues duplicadas, mas você pode pesquisar ou perguntar na mailing list https://zfsonlinux.topicbox.com/groups/zfs-discuss e nas issues do GitHub https://github.com/openzfs/zfs/issues
      A primeira parece estranha, mas é um frontend web normal da mailing list
    • Estou passando pelo mesmo problema. Às vezes, um arquivo parece corrompido não só no snapshot, mas também na versão atual do arquivo
      Não dá para mover nem modificar; só excluir. Não faço ideia de por que esses arquivos estão sendo corrompidos. Felizmente, eram todos ISOs grandes de Linux, então não foi catastrófico