Quais são as soluções disponíveis para desduplicação em nível de bloco ou mais detalhada?
Existem aqueles baseados em arquivo - com abordagem "Copy-On-Write".
Estou procurando por "cópia na gravação" no nível do bloco, para poder procurar periodicamente blocos comuns ou - de preferência - partes de arquivos, mesclá-los e sinalizar a maneira de uso do CoW. Existe algo assim disponível ou ainda precisa ser criado? Não tenho certeza se a desduplicação do Btrfs está no nível de bloco/arquivo/subparte? Existe o LessFS, mas não tenho certeza de qual nível de desduplicação ele fornece? Talvez outra solução?
Responder1
No que diz respeito à desduplicação em nível de bloco, acho que o ZFS é a melhor implementação incontestada atualmente. Na verdade, ele não foi projetado para otimização posterior, porque sua desduplicação (se ativada) é incorporada diretamente nas funções de leitura/gravação. Por causa disso, pode ser um pouco caro para a memória sob carga, ao tentar manter as partes mais relevantes da tabela de desduplicação na memória, mas o ZFS é bom em se restringir a consumir não muito mais que 50% da memória, o que dependendo de quantidade de memória instalada pode parecer bastante arbitrária (50% de 2 Gb versus 50% de 64 Gb, especialmente se poucas ou nenhumas tarefas de usuário precisarem de memória).
Dependendo do que você deseja usá-lo, você tem algumas opções:
OpenIndianaparece ter algumas boas opções de desktop e servidor, baseadas no Solaris
O FreeBSD (desde 9.0) possui uma versão bastante avançada do ZFS (que inclui desduplicação) integrada. Uma notável distribuição derivada do FreeBSD (então MonoWall) éNAS4Free, o que torna muito fácil criar um NAS.
O Linux tem algumas opções, algumas com desduplicação, outras sem. Já que você está procurando desduplicação, o mais notável que vi ézfsonlinux. Não tenho certeza de qual é o progresso deles ou quão estável é o projeto, mas definitivamente parece promissor.
Quanto a qualquer coisa com desduplicação de bloco parcial, não vi NADA até agora que relate a capacidade de fazer isso.
Responder2
Sua pergunta é um pouco confusa devido ao termo "blocos", que é uma palavra muito sobrecarregada quando se trata de discos e sistemas de arquivos. (Mas o contexto ao seu redor ajuda a esclarecer.) O Btrfs não lida com "blocos" de sistema de arquivos de tamanho fixo, ele lida com "extensões" de tamanho variável. (Embora, de forma confusa, também defina zonas de bloco de tamanho variável.) O ZFS lida com "blocos" do sistema de arquivos, em parte ou principalmente porque isso apresenta problemas significativamente mais fáceis de resolver. Tanto o Btrfs quanto o ZFS estão cientes dos "blocos" no nível do disco, que são eles próprios abstrações. (Então também temos "armazenamento em nível de bloco", que pode ter um significado semanticamente diferente.) Posso ter essas descrições um pouco erradas, não claras o suficiente ou não 100% precisas. (Se você precisa de clareza e 100% de precisão no tópico de bloqueios, finja que não leu isso. Se você só precisa de um entendimento aproximado para continuar, então você deve estar pronto para prosseguir.) O ponto principal desta resposta é não para definir perfeitamente "blocos", mas a discussão abaixo, que é muito mais da minha conta.
Como escreveu @killermist, o ZFS oferece suporte nativo à desduplicação em nível de bloco [ZFS].
Não está habilitado por padrão no ZFS. Ligá-lo sem memória suficiente envolve um grande impacto no desempenho. Além disso, curiosamente, o ZFS precisa de uma quantidade razoável a mais do que a regra prática recomendada de "1 GB de RAM por 1 TB de armazenamento", para caber toda a tabela de hash na RAM. Mas mesmo assim, dependendo do hardware, você ainda pode obter velocidades de gravação de mais de 40 MB/s. Eu entendo isso na tecnologia da era de 2008 executando unidades da era de 2015. Perfeitamente aceitável para mim, principalmente para dados de arquivo. A maior desvantagem da desduplicação do ZFS é que ainda não existe uma maneira elegante de fazer isso no modo "lote/offline" (ou mais precisamente "fora de banda"), além de ativar a desduplicação, copiar tudo para um novo diretório temporário no mesmo sistema de arquivos, excluindo os originais e, em seguida, movendo o conteúdo temporário (agora desduplicado) de volta. (Exceto que a exclusão dos arquivos antigos pode levar mais tempo do que a operação inicial de cópia/desduplicação.) O que normalmente faço é esperar até ter que rearquitetar periodicamente o array de qualquer maneira para alterar o layout fundamental e copiar do array antigo para o novo, com desduplicação ativada.
A desduplicação do Btrfs é indiscutivelmente um pouco mais incompleta, com apenas utilitários de terceiros disponíveis atualmente para fazer o trabalho. (Mas que usam APIs de kernel bem suportadas e/ou uma opção bem suportada para cp; e de qualquer forma exigindo sua própria lógica para determinar duplicatas, o que se espera que seja totalmente preciso.) Um benefício potencial, porém, são esses utilitários estão "fora de banda". O custo para a maioria dos utilitários, porém, é que eles prejudicam o desempenho enquanto trabalham - o que pode levar horas, dias e até semanas para ser concluído. (Pessoalmente, prefiro lidar com o desempenho de gravação sempre mais lento da desduplicação ZFS em banda, do que martelar meus HDDs por dias, digamos, uma vez por ano.)
Duas soluções Btrfs que conheço que lidam com "blocos" (mas em outra definição) em vez de arquivos, sãoabelhas, eduper.
O Bees, por exemplo, define arbitrariamente um tamanho de "bloco" na primeira execução, com base na memória disponível e possivelmente em outros fatores. (Embora eu provavelmente esteja deturpando seu propósito, recursos, mecanismo e prós/contras, como não o uso, apenas avaliei-o recentemente como uma opção.)
O Bees é indiscutivelmente um pouco híbrido, pois foi projetado para funcionar continuamente e não martelar os discos com tanta força - embora ainda não seja tecnicamente "in-band" como a desduplicação do ZFS. Ele simplesmente coleta duplicatas após o fato e tenta desduplicá-las com um leve toque. Trabalhar com um tamanho de bloco definido arbitrariamente significa que, por design, ele caberá na tabela hash na RAM. A desvantagem (presumivelmente) é que pode haver extensões em um "bloco" que são iguais, mas as abelhas podem não desduplicar porque os "blocos" em que estão são diferentes.
Tenha em mente que mesmo utilitários que executam especificamente a desduplicação Btrfs em nível de "arquivo" (comodormir,duperemove,rmlinte outros), ainda podem satisfazer seus requisitos. Não posso ter certeza, mas parece que sim. Isso ocorre porque mesmo um comando "cp --reflink=always" não está realmente desduplicando "arquivos". Está desduplicando o Btrfsextensões. Quando um "arquivo" vinculado novamente é alterado, o Btrfs apenas desduplica as extensões que mudam, em suas próprias extensões exclusivas. O restante do arquivo permanece desduplicado. É assim que arquivos grandes desduplicados ainda podem divergir como se fossem seus próprios arquivos exclusivos, mas ainda assim serem em sua maioria desduplicados.
(É também por isso que é tão difícil determinar se um "arquivo" foi vinculado novamente ou não, porque esse conceito nem faz sentido. Todos os arquivos de um arquivoextensõespodem eles próprios ser religados a outras mesmas extensões, um conceito que faz sentido, mas coincidentemente é uma questão particularmente difícil de responder. É por isso que, a menos que um utilitário de desduplicação Btrfs monitore o que já foi desduplicado, não vale a pena tentar "detectar" se um arquivo já foi desduplicado. Não há nenhum atributo como refcount para inspecionar. De qualquer maneira, é mais fácil desduplicá-lo novamente. Por outro lado, determinar se um arquivo inteiro tem link físico à moda antiga é trivial. Basta verificar a contagem de st_nlink para um determinado inode.)
A falta de "clone de arquivo inteiro" é na verdade uma característica intrínseca de todos os sistemas de arquivos CoW que suportam snapshots e/ou desduplicação "gratuitos", e é verdadeira quer se trate de extensões Btrfs, blocos ZFS ou qualquer outra coisa. É por isso que qualquer um deles provavelmente pode ser uma resposta à sua pergunta. (Existem pelo menos três outros sistemas de arquivos CoW que podem ou estão planejados para fazer tudo isso, que eu saiba: nilfs2, bcachefs e xfs.)
Embora você não tenha mencionado isso, nenhuma tecnologia de desduplicação, que eu saiba, reconhece o tipo de arquivo. Em outras palavras, nenhum desduplicador sabe ignorar os metadados *.jpg e considerar apenas os dados da imagem compactada para desduplicação. Da mesma forma, nenhum deles considera números mágicos de arquivo (pelo menos para determinar o que considerar para desduplicação). Esse poderia ser um recurso matador – embora certamente exija atualizações de definição constantes e contínuas. E pode ser muito difícil de projetar, ao mesmo tempo que trata os arquivos como uma coleção M:M abstrata de extensões, blocos, etc.