Bulat_Ziganshin
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:| Непойму, поддержка stdin что ли сбойная в srep. |
в srep в прицнипе нет вариантов работы с stdin на stdout и при сжатии и при распаковке, надо выбрать что-либо одно. связано это с использованием future-lz, который в свою очередь необходим чтобы при распаковке не использовать RAM = размеру словаря. вам же не понравится 700 гиг озу использовать при распаковке, верно? 
то, чего вы добиваетесь, достижимо как раз-таки с fa'next в режиме дедупликации, но чисто для тестов. а для работы возьмите какой-нибудь популярный, проверенный тысячами пользователей формат, хотя бы zpaq (оригинальный от махони, а не эксперименты от franz) или rar7
Добавлено:
Цитата:
емнип, поддержки больших словарей в rep в прицнипе нет, и скорее там просто парсер не обнаружил переполнения при умножении 8000 на 1048576. проверьте по используемому размеру памяти
Цитата:| Во-первых у srep тоже есть предел по просматриваемой дистанции. Свой размер словаря, если угодно. И всё |
предел есть. и он равен размеру файла да-да, srep настолько тупой, что он просто не умеет выкидывать из словаря старые данные, как это делают и rep и любые lz-методы
Цитата:| Сам srep - это в принципе костыль, который хард насилует вместо оперативки |
нет. обычные lz методы, а также rep (и новый long range в rar7) хранят весь словарь в озу. srep же вместо каждого блока по 512 байт хранит его 20-байтный хеш, поэтому упаковка и требует в десятки раз меньше озу, чем размер входного файла (=размеру словаря)
а вот при распаковке хешами уже не обойдёшься, поэтому предусмотрено использование hdd если озу не хватает (заметь, что озу может не хватить именно потому, что словарь больше). но даже со свопом на hdd он работает очень быстро, другое дело что использование srep+архиватора - в принципе калечная идея. srep должен быть встроен внутрь, как и сделано в fa'next
тем не менее, если хотите гарантий что srep при распаковке обойдётся без hdd - используйте srep -m0 при упаковке, вроде там уже поддерживались словари >4 гиг. srep -m0 - это как раз аналог rep из freearc (и long range из rar7), со sliding dictionary фиксированного размера
Цитата:| Достаточно взять любой из озвученных архиваторов, указать ему такой же словарь, каким прикидывается твой srep, и получить соизмеримый результат, который может минимально отличаться только за счёт разной настройки самого lzma2 или rar алгоритма, а так же применяемых оптимизаций. |
не совсем. обычные lz алгоритмы используют ~10x озу и оптимизированы для поиска даже небольших совпадений в несколько байт. rep и rar7 long range используют ~1.5x озу и находят только длинные совпадения, начиная с десятков или сотен байт. srep же использует 0.05x озу (храня только хеши) и находит только совпадения от 512 байт
вы можете настроить обычный lz алгоритм на exhaustive search, и тогда он по идее вещей сожмёт не хуже srep, но используя в 100 раз больше озу и работая в 100 раз медленней. кроме того, lzma пока в принципе не поддерживает словари >4ГБ
Добавлено:
Цитата:| Если сможешь этот srep заставить работать вообще. И не потеряешь потом конкретную его версию, ибо они между собой не совместимы. |
srep сохраняет обратную совместимость начиная с версии 0.8. т.е. любая версия с большим номером распакует архивы, созданные более ранней
Цитата: FreeArc, при всей своей относительной малоизвестности, на самом деле очень ценный, и даже объективно незаменимый архиватор для тех, кому важен уровень сжатия. Причём зависимость от всяческих внешних "фильтров" сразу отбрасываем, как нечто невнятное и ненадёжное, вроде модификаций 7z с самопальным форматом хранения zstd.
|
не удивлюсь, если пользователей 7z с zstd больше, чем всех юзеров freearc вместе взятых. когда у меня на сайте собиралась статистика, их было несколько десятков тыщ
Цитата:| 7z - лучше всех пакует .exe .dll и т.п. И даже на больших архивах, где повторов на длинных дистанциях не слишком много, нередко обходит arc по сжатию. Однако, в отличие от последнего, не поддерживает информацию для восстановления. |
recovery info в freearc - это просто xor. лучше считайте, что никакой RI там просто нет
Добавлено:
Цитата:| Команда test archive ничего не распаковывает в temp (если не использовать внешний srep), для встроенных rep/4x4/tor/xlz4/lzma это не требуется |
вроде в доке по 0.40 описано, что в цепочку алгоритмов A+B будет вставлен tempfile, если озу для одновременной работы A и B не хватает. именно это у вас и происходит, просто при тестировании после упаковки озу оказывается более засрано, чем при standalone тестировании |
