» FreeArc (часть 4)

Прошу протестировать.
Я создал Яндекс.Диск,
в котором открыл (надеюсь, только для чтения) папку FreeArc.
http://yadi.sk/d/gytcnNw85PaCA
В ней лежат файлы arc.ini.
(с разными датами)
Открывается эта папка? Читаются файлы?

Цитата:

советую заменить "-m3 -l512 -c256" на -m5

Bulat действительно с этим параметром srep3.93a_beta_x86_11-10-14 работает безукоризненно.

Спасибо большое и дай бог вам крепкого здоровья!

Shuld
да. да

Цитата:

пока только так. я должен научить fa передавать опцию -ssw в 7-zip

Булат, есть ли уже на данный момент решение этой проблемы (сжатие открытых для записи файлов в 7z)?

[more] опции d: s: rep
по сравнению с srep позволяют найти повторения меньшей длины на дистанции больше словаря lzma

по умолчанию:
dispack070: 779,902,969 bytes in 5.554 seconds
srep:m3f:mem75p-200mb:s:v2: 620,286,651 bytes in 353.974 seconds
delta: 621,104,395 bytes in 5.288 seconds
lzma:254m:max: 341,086,498 bytes in 340.848 seconds

только rep:
dispack070: 779,902,969 bytes in 5.741 seconds
rep:761mb:d268mb:s16: 626,250,060 bytes in 32.136 seconds
delta: 627,085,212 bytes in 5.273 seconds
lzma:254m:max: 341,090,467 bytes in 1949.573 seconds
(тут свапинг)

rep+srep:
dispack070: 779,902,969 bytes in 5.616 seconds
rep:761mb:d300mb:s16: 626,309,620 bytes in 23.603 seconds
srep:m3f:mem75p-200mb:s:v2: 620,135,115 bytes in 349.172 seconds
delta: 620,953,939 bytes in 4.883 seconds
lzma:254m:max: 341,073,105 bytes in 339.529 seconds
(srep нашел еще ~6mb)

в данном случае, если уменьшить d:, получается лучший результат:
dispack070: 779,902,969 bytes in 5.210 seconds
rep:761mb:d238mb:s16: 626,017,293 bytes in 24.804 seconds
srep:m3f:mem75p-200mb:s:v2: 619,855,435 bytes in 348.437 seconds
delta: 620,674,703 bytes in 5.070 seconds
lzma:254m:max: 341,067,209 bytes in 338.716 seconds
(то есть за счет того, что он ищет повторения от 16 байт, которые lzma кодировала бы разными записями в словаре) [/more]

Bulat_Ziganshin, FreeArc не переезжает ?

Bidding farewell to Google Code

tsmv0k
эти изменения в пределах 0.01% я бы отнёс на случайные флуктуации. единстенное что тут могло бы иметь смысл - уменьшение времени работы, и то неясно почему свопинг был только в одном случае, может -lc- поставили?

а вообще можно попробовать сделать сначала srep, потом rep чтобы добить остатки

slech
Булат, подскажите пжалуйста как можно проследить причину проблемы с прекращением архивации.

Есть задача по архивации 4-ёх баз. Более года всё работало хорошо.


Код: D:\Backup\DBIntermediate>Arc a -mx4 --logfile=BackupArc.log -w=D:\Backup\DBIntermediate -ep -ag%Y%m%d DBIntermediate_backup_.arc @DBIntermediate.lst
FreeArc 0.67 (November 11 2013) Creating archive: DBIntermediate_backup_20150301.arc using exe+delta+lzma:96mb:normal:32:mc16, $obj => delta+lzma:96mb:normal:32:mc16, $text => dict:64mb:75%+lzma:96mb:normal:32:mc16, $compressed => 4x4:tor:8mb:c3, $wav => tta:m1, $bmp => mm+lzma:96mb:normal:32:mc16
Memory for compression 320mb, decompression 128mb, cache 16mb
Compressed 4 files, 48,826,658,816 => 5,981,402,928 bytes. Ratio 12.25%
Compression time: cpu 23838.55 sec/real 14722.44 sec = 162%. Speed 3.32 mB/s
All OK

Bulat_Ziganshin

День добрый. Возникла ошибка с потреблением памяти при распаковке архивов со словарем lzma в 1гб. Судя по тому, что пишут юзеры, процессу не выделяется больше 20мб и в итоге выдает ошибку "Not an SREP compressed file". Для сжатия кроме srep+lzma ничего более не использовалось. Для распаковки используется unarc.dll (12 декабря 2012) + cls-srep.dll. Так же проблема происходит не у всех, у большинства всё спокойно ставится. При более маленьком словаре такой проблемы нету (либо бывает лишь у единиц). Более подробно тут. Есть какие либо соображения на этот счет?

дай lt успешно созданного архива. добавь -di -di+$#! и сравни вывод умпешной и неуспешной команд

на гитхаб перееду, я от гугла использую только багтрекер, он там очень удобный


Цитата:

пока только так. я должен научить fa передавать опцию -ssw в 7-zip

ещё не сделано. но я поправлю, это недолго

spider919191
1. паковать lzma с 1 гб ловарём категорически нельзя - cv. в заголовке статью "Почему для использования 2+ гб памяти желательно установить 64-битную версию Windows "
2. вы хотя бы параметры упаковки привели...

Цитата:

дай lt успешно созданного архива. добавь -di -di+$#! и сравни вывод умпешной и неуспешной команд

lt DBIntermediate_backup_20150324.arc

Код: FreeArc 0.67 (March 15 2014) listing archive: DBIntermediate_backup_20150324.arc

Archive type: FreeArc
Total bytes: 49,715,728,384
Compressed bytes: 6,139,778,739
Ratio: 12.35%

Directory blocks: 1
Directory, bytes: 256
Directory, compressed: 175
Solid blocks: 1
Avg. blocksize: 46 gb

Compression memory: 192 mb
Decompression memory: 96 mb
Dictionary: lzma:96mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 49,715,728,384 6,139,778,739 4 exe+delta+lzma:96mb:normal:16:mc8
-----------------------------------------------------------------------------
4 files, 49,715,728,384 bytes, 6,139,778,739 compressed
All OK

Bulat_Ziganshin

1. Ошибка возникает и у пользователей с х64, так же как и у многих на х32 системах ставится на ура, тч дело не в этом. Да и памяти при распаковке используется максимум 1.2гб, а не 2+.

2. srep:mem256m:m2f+lzma:1024mb:a1:bt4:... (остальное светить бы не хотелось).

З.Ы.
Паковать с таким словарем я вряд ли снова стану, но всё-таки хотелось бы узнать в чем конкретно проблема.

Цитата:

добавь -di -di+$#! и сравни вывод успешной и неуспешной команд

это надо добавлять в команды архивации

Цитата:

памяти при распаковке используется максимум 1.2гб, а не 2+.

может прочтёшь статью, а не только её название? )))

Добавлено:

Цитата:

процессу не выделяется больше 20мб и в итоге выдает ошибку "Not an SREP compressed file"

честно говоря, не представляю как это возможно. для того чтобы srep что-то написал, он должен что-то получить от lzma, а для этого lzma должен выделить весь свой гигабайт озу

Добавлено:
вообще у меня проклёвывается мысль вшить srep в unarc.dll, на всякий случай. может это решить проблемы, или хотя бы избавит от сомнений кто в них виноват

Добавлено:

Цитата:

srep:mem256m:m2f+lzma:1024mb:a1:bt4:... (остальное светить бы не хотелось).

кинь lt от архива, можегшь с затёртыми параметрами lzma

Bulat_Ziganshin
Понял, добавил. Сообщу результат как отработает задача. Спасибо!

Задача отработала успешно:


Код: Compressed 4 files, 49,172,566,016 => 6,146,246,240 bytes. Ratio 12.50%
Compression time: cpu 13723.78 sec/real 9259.52 sec = 148%. Speed 5.31 mB/s
All OK

Цитата:

2. srep:mem256m:m2f+lzma:1024mb:a1:bt4:... (остальное светить бы не хотелось).

Спидр такой олень...

Цитата:

2. srep:mem256m:m2f+lzma:1024mb:a1:bt4:... (остальное светить бы не хотелось).

Какие могут быть секреты в обычном lzma ? Там зашифрован пароль от кредитной карты ?

Делюсь опытом подключения внешнего компрессора zpaq 7.04.
Копируем zpaq.exe в папку "FreeArc\bin".
Для сжатия создаём отдельный arc2.ini, в нём

Код: [External compressor:zpaq]
packcmd = {compressor} add $$arcpackedfile$$.tmp $$arcdatafile$$.tmp -threads 1 -method {option}
unpackcmd = zpaq x $$arcpackedfile$$.tmp.zpaq
packedfile = $$arcpackedfile$$.tmp

слишком замученно. проще создать arc-zpaq.ini, в него внести содержимое твоего arc2.ini, кинуть к arc/freearc и никаких cfg в комстроке указывать не нужно

ты просто недопонял концепцию ini-файлов и внешних компрессоров. более полный ini с командами и упаковки и распаковки никак не мешает работать всему остальному. всё равно эта команда упаковки используется только когда ты указал метод сжатия zpaq. и я рекомендую называть такие файлы arc-COMPRESSOR.ini, поскольку в будущем freearc вероятно будет читать только конфиг файлы начинающиеся на "arc-", ну и чтобы не путаться в них названия типа arc2 не очень-то удобны

разве что у тебя старый arc.exe который не подхватывал все файлы arc*.ini, ну тогда просто обнови его

PS: да, дошло. в доке поддержка arc*.ini не упомянукта, а ридми к каждой версии читать замучаешься. my bad

[more]
Цитата:

может прочтёшь статью, а не только её название? )))

Да, извиняюсь, прочитал уже. Но всё равно не пойму почему тогда подобное вылетает на некоторых х64 системах и ставится на некоторых х32 (причем у одного из тестеров всего 2гб оперативы на пк и игра поставилась нормально). Кстати, какой-то пользователь писал что после обнов винды происходит подобное, так ли оно на самом деле хз.


Цитата:

кинь lt от архива, можегшь с затёртыми параметрами lzma

FreeArc 0.67 (December 12 2012) listing archive: data.bin

Archive type: FreeArc
Total bytes: 6,339,269,769
Compressed bytes: 4,938,474,622
Ratio: 77.9%

Directory blocks: 1
Directory, bytes: 586
Directory, compressed: 401
Solid blocks: 1
Avg. blocksize: 6 gb

Compression memory: 4096 mb
Decompression memory: 4096 mb
Dictionary: lzma:1gb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: Yes

Encryption algorithms: aes-256/ctr

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
* 31 6,339,269,769 4,938,474,622 14 srep+lzma:1024mb:a1:bt4:хххххх+aes-256/ctr:n1000:r0:ie0fc8e11546fec32cc068e045e54b093:s90b5f0686a41bf0948aeadf57f0b73006ffc9f12a065a2d7629fee51ab9950d9:c298b
-----------------------------------------------------------------------------
14 files, 6,339,269,769 bytes, 4,938,474,622 compressed
All OK
[/more]

Добавлено:
V2driver

Я сюда не всякое быдло слушать пришел. Но я, конечно же, учту твое сверх-авторитетное мнение.

muzf

Просто не всем нубам их знать надо, пусть сами читают доку, а не лезут в чужие раздачи.

spider919191
ты меня извини, но здесь я srep:mem256m ну никак не вижу. а этот параметр нужен как раз распаковщику чтобы ограничить использование ОЗУ

хез, может стоить его вшивать в сам архив, как защиту от дурака

Bulat_Ziganshin

Это прописано в arc.ini + cls.ini.

spider919191
гм, на этом мысль останавливается. разве что возникает ещё большее желание встроить это внутрь freearc чтобы уж точно знать кого бить по наглой рыжей морде

Bulat_Ziganshin
спасибо!
а опция rep d: это может быть одно из двух
- на дистанции до от начала данные пропускаются
- если между двумя любыми повторениями дистанция меньше, то они пропускаются

это вопрос по поводу rep+srep
Добавлено:
- может быть еще: данные кодируются, если встречается одна или более из дистанций больше

Bulat_Ziganshin
Если при упаковке консольной версии (хотя может с GUI тоже самое), с помощью внешних упаковщиков (precomp, srep, lzma_x64 etc...), прервать упаковку, то не удаляются временные файлы с папки temp, можно это как-то поправить? А то каждый раз руками чистить ни есть гуд)

Edison007007
нет

SREP 3.9 beta released:English release notes
Russian release notes
Download

Bulat_Ziganshin
Про адресное пространство (нехватку памяти)

Ранее уже говорили
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=2240#13

Провел эксперименты с GUI, двухъядерный процессор, кое-что непонятно.
Привожу методы, возникает ли проблема, размер использованной памяти (уже из консольной версии)
rep:1gb:96:c16:d4m:s32+4x4:tor:6:4mb:h8mb - проблема - tempfile 1232 mb rep:1gb:96:c16:d4m:s32+4x4:i0:tor:6:4mb:h8mb - норм - 1282 mb,
rep:1gb:96:c16:d4m:s32:h25+4x4:tor:6:4mb:h8mb - норм - 1218 mb
rep:1gb:96:c16:d4m:s32:h25+4x4:i0:tor:6:4mb:h8mb - норм - 1202 mb

rep:1gb:96:c16:d4m:s32+4x4:i0:tor:6:8mb:h8mb - проблема - tempfile 1232 mb
rep:1gb:96:c16:d4m:s32:h25+4x4:tor:6:8mb:h8mb - проблема - 1268 mb
rep:1gb:96:c16:d4m:s32:h25+4x4:i0:tor:6:8mb:h8mb - норм - 1236 mb

Где вижу противоречие?
Во второй строчке требуется память 1282 mb - и все нормально
Во второй строчке от конца требуется память 1268 mb - и проблема
(в этом случае в GUI места не хватило, в консоли - хватило, такое не первый раз)

Раз на раз не приходится, и чисто случайная нехватка памяти?
Или дело еще и в используемых методах?
(Могу по этим двум методам повторить)

Добавлено:
Или есть неточности в информации, которую выдает консольная версия?