Tengo alrededor de 100 TiB de datos gzip comprimidos en volúmenes de nube. En mi camino para ejecutar una deduplicación a nivel de bloque (duperemove para btrfs), encuentro que se comprimió sin -n, lo que provoca una diferencia a nivel de bloque en la salida comprimida para archivos que de otro modo serían idénticos.
Además de recomprimirlo todo con gzip -n, ¿existe algún otro atajo para hacer que cientos de millones de archivos comprimidos "pierdan" ese encabezado? y si ya tengo que recomprimirlos todos, ¿debería buscar también otras optimizaciones, como --rsyncablemaximizar las posibilidades de deduplicación?
(Los datos tienen muchas posibilidades de contener muchos engaños, estamos hablando de volcados completos diarios de grandes tablas de bases de datos)
Respuesta1
Podrías usar zcat para extraer los archivos y luego calcular una suma de verificación para cada archivo:
for x in *.gz
do
zcat $x | sha256sum > $x.sum
done
luego verifique esos archivos *.gz.sum en busca de duplicados. Cada vez que elimines un duplicado llamado "algo.gz.sum", elimina también el "algo.gz" correspondiente.
Respuesta2
Respondiendo a la primera mitad de mi pregunta sobre: cortar el sello de fecha/nombre de un archivo gzip. no, todavía no he encontrado un fragmento de código listo para usar, pero encontré tiempo para instalar vbindiff, una herramienta visual de diferenciación binaria, y descubrí que el encabezado no estaba comprimido y, por lo tanto, la secuencia comprimida real es idéntica a gzipy gzip -n. y todo lo que queda es manipular unos pocos bytes al principio de los archivos comprimidos para obtener la versión unificada. un pequeño programa en C resolverá mi problema, a menos que alguien sepa algo sedde binarios :-)
En cuanto a la segunda parte, tendré que experimentar con un montón de datos. Si tengo algún resultado definitivo, lo publicaré aquí.