Melhorias no recurso de deduplicação do OpenZFS, mas recomendação continua sendo evitar seu uso

• O Fast Dedup do OpenZFS 2.3.0 melhorou bastante em relação ao dedup antigo, mas ainda é um recurso cujo custo e pré-requisitos precisam ser avaliados antes de ativá-lo como se fosse um padrão para usuários comuns
• O dedup funciona sem regravar blocos já armazenados, apenas aumentando referências, então todos os caminhos de escrita e liberação passam a ter custo de consulta e atualização da dedup table
• O método antigo tinha alta carga de memória e IO por causa da amplificação read-modify-write da tabela baseada em ZAP, da live entry list que não podia ser recuperada durante a transação e das unique entries sem ganho real
• O Fast Dedup reduz a live entry de 424 bytes para 216 bytes e dá ao operador mais controle sobre custos com dedup log, flush incremental, zpool ddtprune, dedup_table_quota, prefetch de DDT e kstats
• Em workloads gerais, pode haver poucos blocos realmente duplicados, e o BRT/block cloning do OpenZFS 2.2 oferece economia parecida com custo menor, então o dedup só vale uso cauteloso quando há muito dado repetido e falta de alternativa zero-copy

---

Funcionamento básico do dedup no OpenZFS

• A deduplicação (dedup) é um recurso do OpenZFS que, antes de gravar dados no disco, verifica se os mesmos dados já existem; se existirem, ele pula a nova gravação e adiciona uma referência à cópia existente
• A parte difícil é que o sistema precisa armazenar e consultar continuamente informações para descobrir rapidamente “se já está no disco” e “onde está”
• A estrutura que guarda essas informações é a dedup table
  • Conceitualmente, ela é uma tabela hash em que o checksum dos dados é a chave, e a localização em disco e a contagem de referências (refcount) são o valor
  • Não são dados do usuário, mas dados estruturais do pool armazenados como parte dos metadados do pool

O custo adicionado aos caminhos de escrita e liberação

• Com o dedup desativado, o OpenZFS aloca espaço no metaslab allocator, coloca o DVA retornado no block pointer e grava os dados
• Com o dedup ativado, ele primeiro consulta o checksum na dedup table
  • Se não houver entrada, ele aloca novo espaço, grava os dados e cria uma nova dedup entry com refcount 1
  • Se houver entrada, ele copia o DVA existente para o block pointer, conclui o IO de escrita e aumenta o refcount
• Blocos alocados com dedup têm a flag D definida no block pointer
  • Na liberação, se houver a flag D, a dedup table é consultada novamente e o refcount é reduzido
  • Se o refcount chegar a 0, a dedup entry é removida e o espaço real é liberado
• Como toda escrita e toda liberação passam por consulta e atualização da dedup table, o dedup só compensa se a economia real de espaço e IO for maior que o overhead de gerenciamento da tabela

Por que o dedup antigo era ruim

• Amplificação da dedup table baseada em ZAP

  • A dedup table antiga usava ZAP, o objeto padrão de tabela hash on-disk do OpenZFS
  • O ZAP é uma estrutura genérica usada também para diretórios, listas de atributos e gerenciamento interno, mas não combina bem com o armazenamento de dedup entries
  • Uma dedup entry típica é formada por uma chave de 40 bytes e um valor que, após compressão, tem cerca de 64 bytes, e um único bloco ZAP de 32K comporta aproximadamente 188 entradas normais
  • Como o OpenZFS não faz escrita parcial de bloco nem sobrescrita no mesmo lugar, atualizar uma única entry já exige ler o bloco ZAP inteiro, modificá-lo e gravá-lo novamente em um novo bloco
  • Como a chave por checksum precisa ter forte resistência a colisões, é pequena a chance de duas entradas aleatórias ficarem próximas no mesmo bloco ZAP, e também é baixa a chance de várias atualizações dentro da mesma transação se concentrarem no mesmo bloco
  • Se houver RAM suficiente para manter a dedup table no ARC, o custo de leitura diminui, mas foi isso que originou a antiga recomendação de que dedup exige muita memória
  • A classe de vdev dedup pode reduzir um pouco a necessidade de memória ao adicionar um dedup vdev dedicado, grande e rápido o bastante, mas em escalas em que o dedup realmente faz sentido ainda é preciso que ele tenha tamanho e desempenho suficientes para acomodar a tabela inteira

• Uso de memória da live entry list

  • O OpenZFS mantém em memória, durante a transação, as dedup entries criadas ou modificadas em uma live entry list
  • Essa estrutura existe para evitar que, quando os mesmos dados são gravados várias vezes ao mesmo tempo, cada thread de escrita conclua que a entrada ainda não existe na dedup table e acabe gravando tudo de novo
  • A consulta verifica primeiro a live entry list
    • Se a entry estiver lá, ele aumenta o refcount
    • Se não estiver, cria uma live entry em estado “in progress”, lê a entry real do ZAP e depois a marca como “ready”
    • Outras threads de escrita que acessarem ao mesmo tempo ficam esperando até ela ficar ready
  • No fim da transação, a live entry list é percorrida e o conteúdo correspondente é refletido no dedup ZAP
  • Cada live entry antiga tinha 424 bytes, e essa memória não ficava no ARC, mas sim em kernel slab memory, portanto não podia ser recuperada quando o sistema estivesse sob pressão de memória
  • A live entry list é esvaziada a cada transação, mas o pico pode crescer bastante quando muitos dados diferentes são gravados em uma única transação

• Unique entries inchavam a tabela

  • O dedup rastreia todos os blocos armazenados em disco, mas o ganho real só existe quando o refcount é maior que 1
  • Uma unique entry com refcount 1 é basicamente um custo pago na expectativa de que os mesmos dados sejam gravados novamente algum dia
  • O dedup acontece em nível de bloco após criptografia e compressão
  • Mesmo que os dados de origem sejam iguais, eles só serão tratados como o mesmo bloco se também coincidirem método de compressão, chave de criptografia e até alinhamento dentro do arquivo
  • Em workloads de propósito geral, há poucos blocos “realmente iguais”, e o custo do dedup tende a ultrapassar o benefício

O que o Fast Dedup melhora

• Redução das live entries

  • O Fast Dedup começa reduzindo o memory footprint da live entry list
  • Ele troca flags com tipos numéricos grandes em ddt_entry_t por bitfields e simplifica os campos de sincronização
  • Também separa em um objeto de estado de IO próprio o estado de 40 bytes usado apenas quando um bloco de dados deduplicado é gravado pela primeira vez ou quando é necessário um repair write
  • O valor da dedup entry antiga tinha 256 bytes, incluindo quatro physical entries
  • Cada physical entry continha três DVAs de 128 bits, refcount e birth transaction id
  • A quarta entry era um vestígio do antigo recurso dedupditto; o OpenZFS moderno só oferece leitura, não novas gravações
  • No Fast Dedup, quando copies= muda e passa a exigir mais DVAs, a variante antiga não é mantida como se fosse uma entry separada; em vez disso, apenas as cópias extras necessárias são alocadas e adicionadas à dedup entry existente
  • O valor da entry na nova Fast Dedup table cai de 256 bytes para 72 bytes
  • Cada entry da live list cai de 424 bytes para 216 bytes

• Introdução do dedup log

  • No método antigo, ao fim da transação, a live entry list era refletida diretamente no dedup ZAP, e isso gerava custo de atualização em nível de bloco mesmo quando 187 entradas vizinhas não tinham relação com a mudança
  • O Fast Dedup adiciona um dedup log com base na observação de que blocos recentemente criados ou deduplicados têm maior probabilidade de voltar a ser deduplicados ou liberados
  • No fim da transação, as mudanças da live entry não são escritas diretamente no ZAP, mas registradas no log
    • O log on-disk é necessário para segurança contra crash
    • O log em memória é mantido para consultas rápidas
  • A ordem de consulta passa a ser live entry list, log em memória e dedup ZAP
  • O log on-disk é usado para reconstruir o log em memória quando o pool é importado

• Flush incremental do log

  • Se, como no método inicial, o log for enviado de uma vez só para o ZAP quando crescer demais, até alguns milhares de entries já podem causar pausas longas
  • O Fast Dedup usa incremental flushing, refletindo parte do log no ZAP a cada transação
  • O volume do flush é ajustado em comparação com o tempo gasto em IO real
    • Em períodos movimentados, grava menos
    • Em períodos tranquilos, grava mais
    • Se o log em memória crescer e causar pressão de memória, o flush pode ser acelerado
  • Para manter o log on-disk como append-only e ainda assim esvaziá-lo sem uma interrupção total, são usados dois logs
    • Um é o active log, que recebe novas mudanças
    • O outro é o flushing log, que é refletido no ZAP
    • Quando o flushing log esvazia, o log on-disk é zerado e os papéis dos dois logs são trocados
  • Em pool scans como scrub ou resilver, o dedup log não tem um conceito estável de posição, então, quando há pedido de scan, o flushing do log é acelerado até tudo ser refletido no dedup ZAP e só então o scan segue pelo método antigo

Gerenciamento de unique entries e recursos operacionais

• zpool ddtprune remove parte das unique entries da dedup table do pool
  • Pode ser definido por age ou por percentage
  • O critério por age é especialmente adequado a workloads em que dados usados recentemente têm maior chance de voltar a ser deduplicados
• Se um bloco cuja dedup entry foi removida por pruning for copiado depois, ele não será deduplicado com o bloco antigo e um novo bloco será alocado
  • Ainda assim, se um unique block antigo passar de repente a ser copiado várias vezes, podem surgir várias referências a um novo bloco
• A propriedade de pool dedup_table_quota limita o tamanho máximo da dedup table
  • Se a criação de uma nova entry ultrapassar o limite, a entry não é criada e a operação segue como uma escrita normal sem dedup
  • Isso também pode ser usado para evitar que, quando um dispositivo dedicado de dedup lotar, a carga transborde para o dispositivo principal
• zpool prefetch -t ddt carrega a dedup table antecipadamente no ARC
  • Pode ajudar no desempenho logo após o import do pool
  • Continua útil no Fast Dedup, já que ainda é necessário acessar o ZAP para consultar entries fora do log e durante o flush
• Também foram adicionados novos kstats e tuneables
  • Linux: /proc/spl/kstat/zfs/<pool>/ddt_stats_<checksum>
  • FreeBSD: kstat.zfs.<pool>.misc.ddt_stats_<checksum>
  • Tuneable no Linux: /sys/modules/zfs/parameters/zfs_dedup_log_*
  • Tuneable no FreeBSD: vfs.zfs.dedup.log_*
• Ferramentas já existentes com suporte a dedup, como zpool status -D, zdb -D e zdb -S, também foram atualizadas para entender a nova estrutura

Compatibilidade com a dedup table antiga

• A maior parte do Fast Dedup exige mudança no on-disk format, então não se aplica diretamente à dedup table antiga
• Mesmo na tabela antiga, podem funcionar recursos que não exigem alteração no formato on-disk
  • dedup_table_quota
  • zpool prefetch -t ddt
  • consulta e contagem de hits de ddt_stats_*
  • ZAP shrink
• Fazer o dedup log funcionar também na tabela tradicional continua sendo um trabalho relativamente straightforward
  • Mas isso não traz os benefícios das live/log entries menores
• Em zpool ddtprune, só o modo de “percentage of uniques” é fácil de adicionar à tabela antiga
  • O modo por age requer dados do novo formato de entry, então não é possível no formato antigo
• No momento, não existe função para converter a tabela antiga para o novo formato
  • Em casos simples, nos quais copies= nunca mudou, seria possível criar um novo ZAP e converter/copiar as entries existentes
  • Uma conversão online é complexa porque exigiria consulta simultânea ou escrita simultânea em ZAP antigo e novo
  • Uma conversão offline é mais simples, mas exigiria colocar o pool offline
  • Se houver variantes com refcount por causa de mudanças em copies=, uma conversão completa pode não ser possível
• Enviar um dataset deduplicado para outro pool novo com suporte ao novo dedup funciona

“Melhorou, mas por que ainda não ativar?”

• O Fast Dedup reduz o overhead em relação ao dedup tradicional e pode ser útil em mais cenários marginais
• Ainda assim, o dedup continua sendo um problema de equilíbrio entre vazão de IO, uso de memória e tamanho da dedup table
• Em workloads de propósito geral, blocos potencialmente duplicáveis podem ser extremamente raros
• No exemplo de um pool de laptop, o resultado simulado de DDT com zdb -S mostrou ganho quase nulo com dedup
  • Das 11,7 milhões de entries, a maioria tinha refcount 1 e era unique
  • A quantidade de entries realmente deduplicáveis era irrelevante diante do total
  • O resultado aparecia como dedup = 1.00
• Nesse tipo de cenário, ativar dedup só adiciona pressão de IO e memória sem praticamente trazer benefício algum

Casos em que BRT/block cloning é melhor

• Desde o OpenZFS 2.2 existe o BRT, ou seja, block cloning ou reflinks
• A dedup table é uma estrutura para descobrir, sem contexto, se “esses dados já existem no disco”
• Em sistemas modernos, às vezes é possível informar à stack de storage que uma operação é uma cópia
  • copy_file_range() em sistemas de arquivos Linux e FreeBSD
  • copyfile() no macOS
  • FSCTL_SRV_COPYCHUNK no Windows
  • Há funções parecidas também em NFS, CIFS, drivers de bloco do sistema operacional, SCSI EXTENDED COPY, NVMe Copy etc.
• Quando o programa cliente e as camadas intermediárias repassam esse sinal de copy offload, o OpenZFS pode apenas aumentar o refcount no BRT
• O BRT não tem custo quando o bloco não é clonado e, quando há clonagem, a entry tem 16 bytes
• No pool de exemplo, o BRT mostrou used 292M; saved 309M; ratio 2.05x
• A economia bruta foi um pouco menor que a da simulação de dedup, mas em nível parecido, sem o grande custo de rastrear todos os blocos não clonados

Critérios práticos para decidir

• O Fast Dedup melhora os três eixos tradicionais do dedup: IO throughput, memory usage e tamanho da dedup table
• O custo catastrófico em caso de erro também diminuiu, e agora o operador tem ferramentas para limitar e limpar a tabela
• Mesmo assim, as condições para valer a pena continuam bem específicas
  • O volume de dados precisa ser muito grande
  • Os mesmos dados precisam ser copiados muitas vezes
  • Não pode haver opção zero-copy melhor disponível no OpenZFS, como block cloning ou snapshot clone
• Se o cliente consegue dar um sinal claro de “quero copiar isto”, o block cloning pode entregar grande benefício com custo muito menor

[GN⁺]

Opiniões do Hacker News

• Seria bom ter deduplicação offline ou deduplicação adiada, que não exigisse desmontar completamente o pool, mas que também não rodasse imediatamente
  Quando se ativa a deduplicação, o fato de cada operação de escrita e liberação exigir consulta e escrita na tabela de deduplicação parece, na maioria dos casos, uma abordagem equivocada. Ao gravar dados, mesmo usando mais espaço em disco, o que se quer é terminar o mais rápido possível; é por isso que não se armazenam arquivos de trabalho dentro de um arquivo 7zip. Seria bom se, mais tarde, quando o sistema estivesse ocioso, o ZFS encontrasse dados duplicados e recuperasse espaço com algo como BRT; parece até que isso poderia fazer parte de uma operação normal de scrub

  • A deduplicação adiada/offline exige reescrita de ponteiros de bloco, e como o ZFS não é um sistema CAS de verdade, é difícil que ele venha a ter uma reescrita de BP adequada
    Como a localização física é incluída por hash na árvore de hashes Merkle, mover a localização física exige reescrever todos os nós internos no caminho até o nó que se quer alterar, o que é caro demais. Um projeto melhor teria sido dividir todos os nós que têm ponteiros de bloco em duas partes: uma com apenas ponteiros lógicos de bloco e que entra no hash da árvore, e outra que contém, como um cache, apenas as localizações físicas correspondentes a esses ponteiros lógicos, mas que não é incluída no hash da árvore Merkle. Assim, a reescrita de BP só precisaria reescrever blocos que não pertencem à árvore Merkle. Com a estrutura atual, é difícil obter o recurso desejado no ZFS, mas talvez seja possível um contorno: se houver uma divergência de hash na leitura, procurar o bloco na tabela de deduplicação pelo hash do ponteiro e realocar o bloco deduplicado. O preço seria algo como uma leitura inútil extra, então não é tão ruim, mas quando a reescrita de BP é impossível, normalmente surgem remendos desse tipo
  • Esse método é igual à metodologia de deduplicação do Windows. Usei bastante e, com hardware suficiente, em geral fiquei satisfeito
    Consome bastante RAM e I/O, mas é possível agendar e limitar o “groveler”. Porém, na época do Windows 2012 R2, sofri uma corrupção que engoliu dados por causa de um bug
  • Isso também pode ser feito com um detector offline de arquivos duplicados
    Por exemplo, há o jdupes ou o duperemove. Enviei PRs para o lado do ZFS e para o duperemove para dar suporte às chamadas de sistema necessárias. A revisão no lado do ZFS demorou, e percebi que tinha esquecido completamente de concluir o assunto, então preciso retomar isso
  • A capacidade de alterar snapshots existentes no ZFS é extremamente limitada, mesmo de uma forma em que os dados sejam totalmente preservados. Então seria bom ter esse recurso, mas, se alguém estava esperando por Block Pointer Rewrite, já teria morrido há muito tempo
  • O lado bom da deduplicação inline é que, se o hash do bloco já existe, não é preciso gravar o bloco de fato
    Em várias situações, isso pode reduzir muito o I/O de escrita. Em arrays de armazenamento com deduplicação, há também uma extensão em que, ao copiar um arquivo entre duas VMs, os dados reais não são copiados; apenas o contador de referências do bloco original é incrementado. Para o sistema operacional, isso parece uma velocidade de escrita absurda, na casa de TB/s, o que é bem interessante

• A afirmação de que “o problema fundamental da deduplicação tradicional é que esse overhead é tão grande que é difícil recuperá-lo, exceto em cargas de trabalho raras e específicas” soa bem estranha
  Já trabalhei com arrays Pure e Dell/EMC, e em cargas de trabalho VMWare normalmente havia ao menos 3:1 de economia com deduplicação/compressão. A abordagem de armazenar apenas uma cópia da imagem base das VMs funciona muito bem. Também vi economia de 6:1 em servidores syslog, onde deduplicação/compressão funcionava bem. A eficácia da deduplicação depende muito do tamanho do bloco que recebe hash, e quanto menor, melhor. À medida que o bloco fica menor, a probabilidade de haver blocos idênticos cresce rapidamente; pela minha experiência, o tamanho de bloco preferido é 4 KB

  • Imagens de VM são informações altamente redundantes, assim como as unidades C de imagens do Windows Server são quase iguais, enquanto o texto original usava como exemplo o conteúdo do próprio notebook
    Além disso, parece estar misturando dois recursos diferentes: compressão e deduplicação. No ZFS, é possível ativar compressão no pool, e quase sempre vale a pena, mas a deduplicação pode ficar desligada
  • Imagens base de VM são uma carga de trabalho rara e específica, um dos poucos casos em que a deduplicação faz sentido
    Porém, se você hospeda VMs sobre um sistema de arquivos ZFS, é bem provável que esteja usando uma estratégia melhor, como clones em nível de bloco ou de sistema de arquivos. Não fazer isso é abrir mão de um dos principais diferenciais do ZFS nesse ambiente. Em um servidor de arquivos genérico ou no uso de desktop/notebook pessoal, normalmente há muito poucos blocos duplicados, então o overhead não compensa. Backups podem ou não se beneficiar, dependendo da implementação e de haver criptografia antes da camada do sistema de arquivos. Compressão é uma história completamente diferente, e a prática recomendada atual no ZFS é ativá-la por padrão para quase todas as cargas de trabalho. Hoje em dia, o custo de CPU é pequeno demais para merecer menção, e a redução de I/O pode ser significativa independentemente da economia de espaço. Para armazenamento típico de logs, pela minha experiência, é possível obter economias muito melhores que 6:1
  • Não testei pessoalmente, mas um número amplamente citado sobre a deduplicação antiga do ZFS é que ela exigia 5 GB de RAM por 1 TB de disco
    Considerando que hoje 1 TB de disco custa cerca de 15 dólares e 5 GB de RAM de servidor custam cerca de 25 dólares, seria necessário um índice de deduplicação de 3:1 só para chegar ao ponto de equilíbrio. Se os dados forem favoráveis, talvez dê para sobreviver com 1 GB por TB, mas, com azar, 5 GB podem não ser suficientes. É por isso que o texto diz que a deduplicação do ZFS tem um pequeno sweet spot em que os dados precisam se encaixar exatamente, e por isso a maioria não se importa com ela. Outros sistemas de arquivos geralmente preferem deduplicação offline, que costuma ter economia melhor
  • Como os benefícios da deduplicação para VMs são conhecidos, ela pode ser eficaz nesse caso. Mas o ZFS não é apenas um SAN corporativo; é um sistema de arquivos de uso geral, então muitos usuários de ZFS não rodam VMs
    Ao dizer que deduplicação/compressão funciona bem em syslog, nos detalhes deduplicação e compressão não são a mesma coisa. No mundo de armazenamento corporativo, as duas costumam aparecer juntas, mas logs provavelmente se beneficiam de compressão, não de deduplicação, e o ZFS já tinha compressão desde o início
  • Naturalmente, faz sentido não manter várias cópias profundas de uma imagem base de VM, mas no ZFS deduplicação não é o método adequado
    Em vez disso, ao clonar a imagem base, ela quase não ocupa espaço antes das alterações. Isso é graças à característica de copy-on-write do ZFS. A deduplicação do ZFS é um recurso que tenta encontrar cópias existentes dos dados gravados em um volume. Para alguns usos, como repositórios de imagens de contêineres, ela pode fazer bastante sentido, mas, se você já sabe desde o início que um dataset é clone de outro, é muito ineficiente

• Antigamente, a deduplicação do ZFS era usada amplamente e trazia grandes ganhos. O uso específico era armazenamento para clusters VMWare, com centenas de VMs Linux e Windows cujo conteúdo era em grande parte igual. Isso foi antes da era do Docker

  • Vejo aqui vários casos de uso de deduplicação em VMs, mas me parece que isso seria muito mais eficiente se fosse implementado no hipervisor do que no sistema de arquivos
  • Concordo. Recentemente recebi um novo notebook de trabalho com o zfs “experimental” do Ubuntu, e usar deduplicação no nix store ajudou muito

• Estou muito animado com a deduplicação rápida. Há anos eu queria usar deduplicação do ZFS nos dados do ArchiveBox, e com a deduplicação rápida parece que finalmente será viável arquivar milhões de URLs em uma coleção e deixar o sistema de arquivos cuidar da compressão global
  Dados de arquivo contêm coisas como jquery.min.js, bootstrap.min.css e imagens de logo repetidas em milhares de snapshots. Outras ferramentas comprimem dentro de um único crawl para criar arquivos wacz ou warc.gz, mas nenhuma ferramenta parece ter tentado comprimir atravessando o banco de dados inteiro de todos os snapshots já feitos. Também fico curioso se alguém já tentou uma abordagem de deduplicação probabilística usando algo como um Bloom filter para não armazenar a tabela completa de hashes de deduplicação. Agrupar cerca de 100 hashes de blocos em buckets e armazenar uma representação ultracomprimida no Bloom filter. Na escrita, consultar no Bloom filter o hash do bloco a ser escrito e, se um possível acerto de deduplicação for detectado, varrer diretamente os 100 blocos daquele bucket para encontrar um hash idêntico. Em teoria, poderia haver uma hierarquia de Bloom filters com resoluções diferentes e, quando a pressão de memória fosse alta, descarregar dinamicamente para disco os filtros de maior resolução. Se a precisão do Bloom filter fosse um parâmetro ajustável, seria possível escolher a preferência entre tempo/overhead de CPU e a proporção de bytes economizados

  • Mesmo com essa mudança, a deduplicação do ZFS ainda é baseada em alinhamento de blocos, então, se os ativos web repetidos não estiverem sempre no mesmo offset dentro dos arquivos WARC, provavelmente não vai casar bem
    O dm-vdo se comporta da mesma forma. Em vez disso, talvez seja melhor usar compressão solid que enxergue intervalos longos, ou descompactar os arquivos WARC em uma estrutura semelhante a diretórios, ou usar um sistema FUSE baseado em content-defined chunking, se existir. Talvez o Seafile faça isso
  • Entendo o caso de uso, mas na maioria dos casos, especialmente neste, acho que seria muito melhor implementar no lado do cliente
    Olhando o padrão WARC, já existe uma forma de deduplicação baseada em hash, usando ponteiros depois que algo é armazenado pela primeira vez. Por isso, este é exatamente um caso em que a deduplicação na camada do sistema de arquivos não é muito boa
  • O uso é um pouco diferente, mas, se você não conhece o zbackup, acho que vai gostar

• Fico curioso por que há tanta dificuldade para fazer isso funcionar direito reduzindo o uso de RAM. Appliances comerciais de armazenamento já faziam isso havia pelo menos uns 10 anos, mesmo em sistemas com “pouca” RAM em relação à capacidade dos discos conectados
  Parece que bastaria armazenar as impressões digitais em um banco de dados e varrer à noite corrigindo os ponteiros de bloco

  • “Corrigir os ponteiros de bloco” é justamente o motivo. Por várias razões, o ZFS não tem capacidade de reescrita de ponteiros de bloco
    É um recurso solicitado há muito tempo e, se se tornasse possível, também permitiria desfragmentação. Já pensei que usar indireção de ponteiros de bloco, como memória virtual, poderia resolver isso com algum custo de velocidade, mas não sou desenvolvedor do ZFS e certamente estou deixando algo passar. http://eworldproblems.mbaynton.com/posts/2014/zfs-block-poin... / https://github.com/openzfs/zfs/issues/3582
  • Corrigir ponteiros de bloco é justamente a única coisa que o ZFS não queria fazer
  • Também há a opção de usar DragonFlyBSD e Hammer2. O Hammer2 dá suporte a deduplicação online e offline e, em muitos aspectos, é muito parecido com o ZFS
    A grande desvantagem é não haver um protocolo de transferência de arquivos usando RDMA. Ouvi dizer que também existe um branch experimental para fazer o Hammer2 rodar no FreeBSD. Mas o FreeBSD também não tem suporte a RDMA. No FreeBSD 15, a Chelsio patrocinou suporte a alvo e iniciador NVMe-oF, mas parece que é apenas TCP

• Basta usar cp --reflink=auto
  Dá para obter deduplicação em nível de arquivo. Esse comando realiza uma cópia leve, em que os blocos de dados só são copiados quando modificados, como um clone ZFS em nível de arquivo. Não é hard link, é uma cópia. O mesmo deve funcionar em outros sistemas de arquivos transacionais copy-on-write que ofereçam suporte a reflink

• Eu queria muito usar ZFS, mas todos os dados obviamente precisam estar criptografados. Só que o uso ficou muito mais complicado do que eu esperava e, quando as coisas se complicam, me surpreendeu ver que muita gente simplesmente não criptografa os dados
  Até o Proxmox tem “Enterprise” no site, então achei que teria suporte a criptografia na instalação padrão, mas, ao tentar usá-lo com criptografia, você perde recursos importantes. Também é preciso olhar bem o issue tracker. Há algumas coisas surpreendentes que eu não esperaria encontrar em um sistema de arquivos de produção

  • A melhor forma de criptografar ZFS é colocar ZFS sem criptografia em cima de um volume criptografado, por exemplo um volume LUKS. A “criptografia” do ZFS deixa coisa demais em texto claro para eu ficar tranquilo

• Gostaria que existisse uma API completamente diferente como sistema de arquivos. A superfície de API de sistema de arquivos de todos os sistemas operacionais é uma bagunça total, presa por compatibilidade retroativa

  • Internamente, o ZFS é essencialmente um armazenamento de objetos. Houve um trabalho para expô-lo como uma API de armazenamento de objetos, mas infelizmente parece que não levou a lugar nenhum
    Tentei encontrar a apresentação, mas não consegui. Achei que a tinha visto no Developer Summit, mas talvez não
  • Por que é uma bagunça e pelo que poderia ser substituída? Uma API no estilo AWS S3 seria uma melhoria?

• Esqueça a deduplicação; usar compressão do ZFS tem uma relação custo-benefício muito melhor

  • A exceção é quando o dataset já é composto por arquivos de mídia fortemente comprimidos
    Em geral, até durante trabalhos com rsync, costuma-se desativar a compressão para arquivos de vídeo grandes. A compressão ajuda pouco, ou nada, em armazenamento ou transferência, mas consome RAM e CPU. A deduplicação é boa para imagens de sistema operacional de Virtual Machines, porque a maior parte do custo de armazenamento vem de imagens base repetidas

• A deduplicação genérica parece boa na teoria, mas na prática muitas vezes não funciona bem. O IPFS usa fragmentos de tamanho variável e rolling hash para deduplicar dados como o rsync, mas, na prática, não faz diferença e só acrescenta complexidade desnecessária