Архивирование исходников

Используйте tar и zstandard:

tar --zstd -cf output.tar.zst input_dir

tar -I zstd -cf output.tar.zst input_dir

zstandard

Спасибо, добрый и мудрый ValdikSS, без тебя бы я и таких слов не узнал)
В работе.

А как этот zstandard в сравнении с xz / 7z ?

А предлагай команду сжатия, а я проверю.
По крайней мере по степени сжатия, я предыдущую без time запустил.

А как этот zstandard в сравнении с xz / 7z ?

Должен быть быстрее..

А что ты потом будешь делать с архивом?.

tar --zstd -cf output.tar.zst input_dir

Что-то сжатие не впечатляет. Получилось 32 и 35, но достаточно быстро имхо.

На гуглодрайв залью.
Попросил человек из Крыма, говорит, что никак не может сам.

Запустил из Krusader'a «tar c сжатием xz»
Посмотрим на результат.
Предыдущее заняло приблизительно 30 мин.

У zstd в широких пределах настраивается степень сжатия и скорость , так-что гугли как в tar подкрутить уровень сжатия

Krusader

tar cJf file.tar.xz source

Да мне хотелось конкретных рекомендаций от уже опытных именно в этом людей.
Твой совет бесполезен, т.к. если бы я проводил неспешное тестирование методов архивирования исходников, я бы естественно прогуглил все варианты)

сжать репо с github'а

Репо с github'а уже содержит упакованные файлы и диффы:

$ ls -l .git/objects/pack/*.pack

Так что сильного сжатия не получишь. «Выигрыш» может дать только перепаковка git-овского pack-а:

$ git gc --prune=now --aggressive

Спасибо, было такое подозрение исходя их результатов попыток упаковки.

было такое подозрение

Только перепаковка pack-а ~ 30+G - это не быстро будет. :)

git --depth=1 ..., лол.

tar cJf file.tar.xz source

300 метров упакованного за 7 минут. Вырубил.
Даже результат упаковки не интересен.
Похоже, что Архивирование исходников (комментарий) от ValdikSS — это оптимальный вариант.
Всем спасибо за умные мысли)

Zstd показывает отличные результаты. В режиме максимального сжатия файлы немного меньше чем с xz, и всё ещё на 25% быстрее. В умолчательном режиме (троечка) прогоняет гигабайты за секунду и сжимает лучше rar и bz2).

там одинаковые файлы присутствуют, многие архиваторы почему-то не складывают их, сжимают отдельно.

Git держит историю упакованной, поэтому данные выглядят как случайные, и жмутся плохо. Для упаковки нужно вызывать git gc --aggressive --prune=now во всех отдельных репозиториях. Их, правда, полтыщи, если не больше. Но в итоге с 50 гигов можно выиграть что-то около десяти. И приготовься к тому, что ОЗУ для этих операций тебе понадобится больше 16 гигов.

одинаковые файлы присутствуют, многие архиваторы почему-то не складывают их, сжимают отдельно.

Тогда стоит попробовать lrzip, у него первой стадией идёт дедупликация.

Вы неправильно делаете, нужно вот так

XZ_OPT='-9 -T4' tar -cvJf archive.txz dir1/ dir2/ dir3/

9e не стоит – намного дольше, а профита пару байтов.

Для zstd параметры можно указывать вот так (мой сниппет)

tar -cvf - dir1/ dir2/ dir3/ | zstd -T4 --ultra -22 -c - > "${SAVEPATH}/${SAVEFILE}"

Xz справляется когда словарь побольше (режим помедленней умолчательного), 7z вроде тоже. Ап bz2 так и не получилось победить по-моему, он мне совсем не понравился. Медленный, неэффективный, фу.

9e не стоит – намного дольше, а профита пару байтов.

После ZPAQ 9e уже не кажется таким уж медленным.

Спасибо, поэкспериментирую попозже.

когда словарь побольше

Ну как бы да, но это работает только если совпадающие части попадают в некое скользящее окно. Поэтому степень сжатия зависит от последовательности файлов.

lrzip это не какой-то особый способ сжатия, он может использовать в том числе и lzma. Но с дедупликацией перед сжатием. Зачем надеяться на большой словарь, если поиск больших повторяющихся кусков можно сделать явно?

git archive

Можно -T0 писать, чтобы использовались все ядра. Многопоточность появлась только в недавних версиях. Возможно на каком-то железе будет лучше когда больше потоков, там зависимость не то чтобы линейная.

А вот памяти нужно значительно больше с каждым потоком.

Комп очень слабый, поэтому обходимся тем, что имеем на данный момент)
Intel(R) Pentium(R) CPU G3260 @ 3.30GHz — это только 2 ядра и памяти 4

XZ_OPT='-9 -T4' tar -cvJf archive.txz

За 5 минут заархивирвало 7 метров и комп встал колом.

Тогда -T1 ?

Но это хорошее сжатие, оно очень медленно будет работать. Если запаковывать не ежедневно, можно сэкономить места.

Тогда -T1 ?

Ну 85 метров за 5 минут. Ты же понимаешь, что для архивирования 35Г это не решение.

Почему это? 85*12 = 1 ГБ в час. Получается полторы сутки — вполне приемлемое решение, если нужно не прямо сейчас, а можно поставить архивироваться на сервере и заниматься дальше другими делами.

T4

рука-лицо.txz

А если число ядер в проце ТС != 4?

T0 же! Автоматический выбор количества потоков, на основе CPU хоста.

Лорчую анонимуса. Я бы перекачал сначала исходники.

repo init --depth 1 -u <git-url> -b <branch>
repo sync -f --force-sync --no-clone-bundle --no-tags -j$(nproc --all)

Я сам не проверял, но ещё кажется можно безболезненно удалить всё кроме каталога .repo, потом repo forall -c 'git checkout'

pigz, быстро и параллельно.

Имхо для передачи самое то.