LINUX.ORG.RU

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

tar --zstd -cf output.tar.zst input_dir
Или, если версия tar старая:
tar -I zstd -cf output.tar.zst input_dir

ValdikSS ★★★★★ ()
Ответ на: комментарий от ValdikSS

zstandard


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

athost ★★★★★ ()
Ответ на: комментарий от rumgot

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

athost ★★★★★ ()
Ответ на: комментарий от rumgot

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

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

Tanger ★★★★★ ()
Ответ на: комментарий от Tanger

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

athost ★★★★★ ()
Ответ на: комментарий от athost

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

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

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

athost ★★★★★ ()
Последнее исправление: athost (всего исправлений: 1)

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

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

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

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

$ git gc --prune=now --aggressive
Deleted ()
Ответ на: комментарий от athost

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

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

Deleted ()
Ответ на: комментарий от Tanger
tar cJf file.tar.xz source


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

athost ★★★★★ ()
Последнее исправление: athost (всего исправлений: 4)
Ответ на: комментарий от rumgot

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

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

linuxnewbie ()

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

i-rinat ★★★★★ ()
Ответ на: комментарий от linuxnewbie

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от athost

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

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}"
linuxnewbie ()
Ответ на: комментарий от i-rinat

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

linuxnewbie ()
Ответ на: комментарий от linuxnewbie

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от linuxnewbie

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

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от athost

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

linuxnewbie ()
Ответ на: комментарий от linuxnewbie

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

athost ★★★★★ ()
Ответ на: комментарий от athost

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

linuxnewbie ()
Ответ на: комментарий от athost

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

anonymous ()
Ответ на: комментарий от linuxnewbie

T4

рука-лицо.txz

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

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

yurikoles ★★★ ()
Ответ на: комментарий от anonymous

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

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

yurikoles ★★★ ()
Ответ на: комментарий от yurikoles

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

yurikoles ★★★ ()

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.