Ich habe etwa 100 TiB komprimierte GZIP-Daten auf Cloud-Volumes. Beim Ausführen einer Deduplizierung auf Blockebene (Duperemove für Btrfs) stelle ich fest, dass die Daten ohne komprimiert wurden -n, was zu Unterschieden auf Blockebene in der komprimierten Ausgabe für ansonsten identische Dateien führt.
Gibt es außer der Neukomprimierung mit gzip -nnoch eine andere Abkürzung, um bei Hunderten Millionen gzippter Dateien diesen Header zu „verlieren“? Und wenn ich sie schon alle neu komprimieren muss, sollte ich dann auch andere Optimierungen in Betracht ziehen, etwa --rsyncableum die Chancen einer Deduplizierung zu maximieren?
(Die Wahrscheinlichkeit ist sehr hoch, dass die Daten viele Duplikate enthalten. Wir sprechen hier von täglichen vollständigen Dumps großer Datenbanktabellen.)
Antwort1
Sie können zcat zum Extrahieren der Dateien verwenden und dann für jede Datei eine Prüfsumme berechnen:
for x in *.gz
do
zcat $x | sha256sum > $x.sum
done
dann überprüfen Sie diese *.gz.sum-Dateien auf Duplikate. Jedes Mal, wenn Sie ein Duplikat namens „something.gz.sum“ entfernen, entfernen Sie auch das entsprechende „something.gz“.
Antwort2
Beantwortung der ersten Hälfte meiner Frage zum Abschneiden des Datums-/Namensstempels einer GZIP-Datei. Nein, ich habe noch keinen fertigen Code gefunden, aber ich habe mir die Zeit genommen, vbindiff zu installieren, ein visuelles Tool zum Vergleichen von Binärdateien, und habe festgestellt, dass der Header nicht komprimiert war und der tatsächlich komprimierte Datenstrom daher mit gzipund identisch ist gzip -n. Es bleibt nur noch, ein paar Bytes ganz am Anfang der komprimierten Dateien zu manipulieren, um die vereinheitlichte Version zu erhalten. Ein kleines C-Programm wird mein Problem lösen, es sei denn, jemand kennt ein Tool sedfür Binärdateien :-)
Was den zweiten Teil angeht, muss ich einfach mit einer Reihe von Daten experimentieren. Wenn ich konkrete Ergebnisse habe, werde ich sie hier veröffentlichen.