Existem scripts de desduplicação que usam o btrfs CoW como dedup?

Question

Procurando por ferramentas de desduplicação no Linux há muitas, veja por exemplo esta página da wiki .

Quase todos os scripts fazem somente a detecção, imprimindo os nomes de arquivos duplicados ou removendo os arquivos duplicados, vinculando-os a uma única cópia.

Com a ascensão do btrfs, haveria outra opção: criar uma cópia CoW (copy-on-write) de um arquivo (como cp reflink=always ). Eu não encontrei nenhuma ferramenta que faz isso, alguém está ciente da ferramenta que faz isso?

    

Answer 1

Eu escrevi bedup para essa finalidade. Ele combina a varredura incremental da btree com a deduplicação CoW. Melhor usado com o Linux 3.6, onde você pode executar:

sudo bedup dedup

    

Answer 2

Eu tentei dormir. Embora seja bom (e tenha alguns recursos diferenciados úteis que podem torná-lo a melhor escolha para muitos), ele parece verificar a totalidade de todos os arquivos de destino para verificações.

Que é dolorosamente lento.

Outros programas, por outro lado, como rdfind e rmlint, são digitalizados de forma diferente.

rdfind tem um recurso "experimental" para usar o reflink btrfs. (E opções "sólidas" para hardlinks, links simbólicos, etc.)

rmlint tem opções "sólidas" para o clone btrfs, reflink, hardlinks regulares, links simbólicos, delete e seus próprios comandos personalizados.

Mas, mais importante, rdfind e rmlint são significativamente mais rápidos. Como em ordens de magnitude. Em vez de digitalizar todos os arquivos de destino para as somas de verificação, ele faz isso aproximadamente:

• Analise todo o sistema de arquivos de destino, reunindo apenas caminhos e arquivos.
• Remova da consideração arquivos com arquivos únicos. Só isso, poupe tempo e atividade de disco. ("Scads" é alguma função exponencial inversa ou algo assim.)
• Dos candidatos restantes, digitalize os primeiros N bytes. Remova da consideração aqueles com os mesmos filesizes mas diferentes primeiros N bytes.
• Faça o mesmo para os últimos N bytes.
• Apenas dessa (geralmente minúscula fração) restante, verifique as somas de verificação.

Outras vantagens do rmlint Estou ciente de:

• Você pode especificar a soma de verificação. md5 muito assustador? Tente sha256. Ou 512. Ou comparação bit a bit. Ou a sua própria função de hash.
• Ele oferece a opção de "clone" do Btrfs e "reflink", em vez de apenas reflink. "cp --reflink = always" é um pouco arriscado, pois não é atômico, não sabe o que mais está acontecendo com esse arquivo no kernel e nem sempre preserva os metadados. "Clone", OTOH (que é um termo abreviado ... Estou apagando o nome oficial relacionado à API), é uma chamada no nível do kernel que é atômica e preserva os metadados. Quase sempre resultando na mesma coisa, mas um pouco mais robusto e seguro. (Embora a maioria dos programas seja inteligente o suficiente para não excluir o arquivo duplicado, se ele não puder primeiro fazer com sucesso um reflink temporário para o outro.)
• Ele tem uma tonelada de opções para muitos casos de uso (o que também é uma desvantagem).

Eu comparei o rmlint com o deduperemove - que também examina cegamente todos os arquivos de destino das somas de verificação. Duperemove levou vários dias no meu volume para concluir (4 eu acho), indo para o full-tilt. O fmlint levou algumas poucas horas para identificar duplicatas e, em seguida, menos de um dia para deduzi-las com o clone do Btrfs.

(Dito isto, qualquer um que se esforce para escrever e suportar software robusto e de qualidade e distribuí-lo gratuitamente, merece grandes elogios!)

Btw: Você deve evitar deduzir o uso de hardlinks regulares como uma solução de dedup "geral", a todo custo.

Embora os hardlinks possam ser extremamente úteis em certos casos de uso direcionados (por exemplo, arquivos individuais ou com uma ferramenta que pode procurar por tipos de arquivos específicos que excedam um tamanho mínimo - ou como parte de muitas soluções comerciais e de backup) pode ser desastroso para "deduplicação" em um sistema de arquivos de uso geral grande. A razão é que a maioria dos usuários pode ter milhares de arquivos em seus sistemas de arquivos, que são idênticos em termos binários, mas funcionalmente completamente diferentes.

Por exemplo, muitos programas geram arquivos de configurações de modelo e / ou ocultos (às vezes em cada pasta que podem ser vistos), que são inicialmente idênticos - e a maioria permanece assim até você, o usuário, precisar deles.

Como uma ilustração específica: Os arquivos de cache de miniaturas de fotos, que inúmeros programas geram na pasta contendo as fotos (e por uma boa razão - portabilidade), podem levar horas ou dias para gerar, mas facilitam o uso de um aplicativo de fotos. Se esses arquivos de cache iniciais forem todos hardlinked juntos, então você abrirá o aplicativo posteriormente em um diretório e ele criará um cache grande ... então adivinhe: Agora, CADA pasta que tem um cache anteriormente com hardlink, agora tem o cache incorreto. Potencialmente, com resultados desastrosos que podem resultar na destruição acidental de dados. E também potencialmente de uma forma que exploda uma solução de backup que não seja sensível ao hardlink.

Além disso, pode arruinar instantâneos inteiros. O ponto principal dos instantâneos é que a versão "viva" pode continuar a mudar, com a capacidade de reverter para um estado anterior. Se tudo está em hardlinked embora ... você "reverte" para a mesma coisa.

A boa notícia é que a desduplicação com o clone / reflink do Btrfs pode desfazer esse dano (eu acho - já que durante a varredura, ele deve ver os arquivos hardlinked como idênticos ... a menos que tenha lógica para não considerar hardlinks). provavelmente depende do utilitário específico que realiza a deduplicação.)