Sua pergunta é um pouco confusa devido ao termo "blocos", que é uma palavra muito sobrecarregada quando se trata de discos e sistemas de arquivos. (Mas seu contexto circundante ajuda a esclarecer.) O Btrfs não lida com "blocos" de sistema de arquivos de tamanho fixo, mas com "extensões" de tamanho variável. (Embora, confusamente, também defina zonas de blocos 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. O Btrfs e o ZFS conhecem os "blocos" no nível do disco, que são abstrações. (Também temos "armazenamento em nível de bloco", que pode ter um significado semanticamente diferente.) Eu posso ter essas descrições um pouco fora, sem clareza suficiente ou com 100% de precisão. (Se você precisar de clareza e precisão de 100% no tópico de blocos, finja que você não leu isso. Se você precisar apenas de um entendimento aproximado para continuar, deve seguir em frente.) O ponto principal desta resposta não é definir perfeitamente "blocos", mas a discussão abaixo, que é muito mais na minha casa do leme.
Como o @killermist escreveu, o ZFS suporta nativamente a desduplicação no nível de bloco [ZFS].
Não está ativado por padrão no ZFS. Ligá-lo sem memória suficiente envolve um alto desempenho. Além disso, anedoticamente, o ZFS precisa de uma quantidade razoável mais do que a regra geral recomendada para "1 GB de RAM por 1 TB de armazenamento", para ajustar toda a hashtable na RAM. Mas, mesmo assim, dependendo do hardware, você ainda pode obter velocidades de gravação de 40 MB / s. Eu entendo isso na era da tecnologia 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 há uma maneira elegante de fazê-lo no modo "lote / offline" (ou mais precisamente "fora da 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 movendo o conteúdo temporário (agora com redução de duplicação) de volta.
A desduplicação do Btrfs é sem dúvida um pouco mais superficial, 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 maneira exigindo sua própria lógica para determinar duplicatas, que se espera seja exata). Um benefício potencial é que esses utilitários são "fora da banda". O custo para a maioria dos utilitários, porém, é que eles diminuem o desempenho enquanto tentam fugir - 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 de ZFS em banda, do que martelar meus HDDs por dias, digamos, terminando uma vez por ano.)
Duas soluções Btrfs que conheço lidam com "blocos" (mas em outra definição), e não com arquivos, são abelhas e dduper .
As abelhas, por exemplo, definem arbitrariamente um tamanho de "bloco" para si 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, já que não o uso, apenas o avaliei recentemente como uma opção.)
As abelhas são indiscutivelmente um pouco híbridas, já que foram projetadas para funcionar continuamente e não martelam os discos com tanta força - embora ainda não seja tecnicamente "in-band" como o deds do ZFS. Ele simplesmente pega 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, caberá a hashtable na RAM. A desvantagem (presumivelmente) é que pode haver extensões em um "bloco" iguais, mas as abelhas não podem deduzir porque os "blocos" em que estão são diferentes.
Lembre-se de que mesmo os utilitários que executam especificamente a desduplicação de Btrfs no nível "arquivo" (como bedup , duperemove , rmlint e outros) ainda podem atender aos seus requisitos. Não tenho certeza, mas parece que sim. Isso ocorre porque mesmo um comando "cp --reflink = always" não está desduplicando "arquivos". Está desduplicando as extensões Btrfs . Quando um "arquivo" refletido é alterado, o Btrfs desduplicata apenas as extensões que são alteradas, com suas próprias extensões exclusivas. O restante do arquivo permanece desduplicado. É assim que os arquivos desduplicados grandes ainda podem divergir como se fossem seus próprios arquivos exclusivos, mas ainda podem ser desduplicados.
(É também por isso que é tão difícil determinar se um "arquivo" é refletido ou não, porque esse conceito nem faz sentido. Todas as extensões de um arquivo podem ser refletidas para outras mesmas extensões, um conceito que faz sentido, mas é coincidentemente uma pergunta particularmente difícil de responder, razão pela qual, a menos que um utilitário de deduplicação do Btrfs acompanhe o que já foi deduplicado, não vale a pena tentar "detectar" se um arquivo já foi deduplicado. Não há nenhum atributo como refcount para inspecionar. É mais fácil deduplicá-lo novamente de qualquer maneira. Por outro lado, determinar se um arquivo inteiro é vinculado à moda antiga, é trivial. Verifique a contagem de st_nlink para um determinado inode.)
A falta de "clone de arquivo inteiro" é, de fato, um recurso intrínseco de todos os sistemas de arquivos CoW que oferecem suporte a instantâneos "gratuitos" e / ou deduplicação, e é verdade se estiver lidando com extensões Btrfs, blocos ZFS ou qualquer outra coisa. É por isso que qualquer um provavelmente pode ser uma resposta para sua pergunta. (Existem pelo menos três outros sistemas de arquivos CoW que podem ou estão planejados para serem capazes de fazer tudo isso, que eu saiba: nilfs2, bcachefs e xfs.)
Embora você não tenha mencionado isso, nenhuma tecnologia de deduplicação, pelo que sei, é compatível com o tipo de arquivo. Em outras palavras, nenhum desduplicador sabe pular 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 deduplicação). Esse pode ser um recurso matador - embora certamente exija atualizações de definição constantes e constantes. E pode ser muito difícil de projetar, além de tratar os arquivos como uma coleção abstrata M: M de extensões, blocos, etc.