Tenho cerca de 100 TB de dados gzip comprimidos em volumes de nuvem. No caminho para executar uma dedução em nível de bloco (duperemove for btrfs), descobri que ele foi compactado sem -n , o que causa diferença no nível de bloco da saída compactada para arquivos idênticos.
Além de recompactar tudo com gzip -n , existe algum outro atalho para fazer com que centenas de milhões de arquivos gziped "percam" esse cabeçalho? e se eu já tiver que recompactar todos, devo procurar outras otimizações também, como --rsyncable para maximizar as chances de desduplicação?
(Os dados têm chances muito altas de conter muitos dupes, estamos falando de lixões completos diários de grandes tabelas de banco de dados)
Você pode usar o zcat para extrair os arquivos e, em seguida, calcular uma soma de verificação para cada arquivo:
for x in *.gz
do
zcat $x | sha256sum > $x.sum
done
verifique então os arquivos * .gz.sum para os dupes. Cada vez que você remover um dupe chamado "something.gz.sum", remova também o "something.gz" correspondente
Respondendo a primeira metade da minha pergunta: corte do carimbo de data / nome de um arquivo gzip. Não, ainda não encontrei um código pronto, mas achei a hora de instalar o vbindiff, uma ferramenta visual de comparação de binário, e descobri que o cabeçalho não estava compactado e, portanto, o fluxo real compactado é idêntico ao gzip e gzip -n , e tudo o que resta para manipular alguns bytes no início dos arquivos compactados para obter a versão unificada. um pequeno programa em C resolverá meu problema, a menos que alguém saiba um sed para binários: -)
Quanto à segunda parte, vou ter que experimentar um monte de dados. Se eu tiver algum resultado definitivo, vou postá-los aqui.
Tags gzip storage btrfs deduplication