У меня около 100TiB сжатых gzip-данных на облачных томах. Когда я собираюсь запустить дедупликацию на уровне блоков (duperemove для btrfs), я обнаруживаю, что они были сжаты без -n, что приводит к блочной разнице в сжатом выводе для в остальном идентичных файлов.
Помимо повторного сжатия всего этого с помощью gzip -n, есть ли другой быстрый способ заставить сотни миллионов сжатых gzip-файлов «потерять» этот заголовок? И если мне уже приходится повторно сжимать их все, следует ли мне также рассмотреть другие способы оптимизации, например, --rsyncableдля максимального увеличения шансов на дедупликацию?
(Вероятность того, что данные содержат много дубликатов, очень высока, ведь речь идет о ежедневных полных дампах больших таблиц базы данных)
решение1
Вы можете использовать zcat для извлечения файлов, а затем вычислить контрольную сумму для каждого файла:
for x in *.gz
do
zcat $x | sha256sum > $x.sum
done
затем проверьте эти файлы *.gz.sum на наличие дубликатов. Каждый раз, когда вы удаляете дубликат с именем "something.gz.sum", также удаляйте соответствующий "something.gz"
решение2
Отвечая на первую половину моего вопроса относительно обрезки штампа даты/имени файла gzip. Нет, я пока не нашел готового кода, но я нашел время, чтобы установить vbindiff, визуальный инструмент для сравнения двоичных файлов, и обнаружил, что заголовок не был сжат, и, следовательно, фактический сжатый поток идентичен и gzip, gzip -nи все, что осталось, это манипулировать несколькими байтами в самом начале сжатых файлов, чтобы получить унифицированную версию. Маленькая программа на C решит мою проблему, если только кто-то не знает a sedдля двоичных файлов :-)
Что касается второй части, мне просто придется поэкспериментировать на куче данных. Если у меня будут какие-то определенные результаты, я их здесь выложу.