» FreeArc (часть 4)

gryhov
понятно, но сама суть delta очень интересная. Будем тестировать.

Bulat_Ziganshin
Когда можно будет ожидать очередную версию?

Bulat_Ziganshin

Цитата:

ОС какая?

Ос - Windows XP x32 SP2 + в ВМ Win 7 x32
Тестовый архив создавался с "-s -msrep:m3f" и с "-s -msrep:m3f+lzma:32mb:ultra"
В arc.ini:
packcmd = srep {options} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = srep -d - - <stdin> <stdout>

ПЫСЫ: с "unpackcmd = srep -d $$arcpackedfile$$.tmp $$arcdatafile$$.tmp" распаковывает нормально.

RuS_UA, FreeArc — планы на будущее, Новости. По первой ссылке видно, что скорее всего - Декабрь 2011 (недолго осталось).

---

Настройки->Шифрование->Профиль шифрования, как можно очистить историю сохраняемых профилей? Там сохраняются пути к файлам ключам, что немного напрягает. В "Файл-ключ" (выпадающее меню) тоже самое.

Bulat_Ziganshin
srep 2.92
а меня FreeArc обидел, не хочет упаковывать\распаковывать с srep, виснет, окошко консольное мелькает и всё, при распаковке появляется консольное окошко, но процесс не идёт
а arc работает нормально

arc a a -msrep:m3f:s250m pdf.TAR.pcf

[External compressor:srep]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} -temp=srep.tmp - - <stdin> <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

Добавлено:
плин у arc распаковка не работает
зато динамик PC заливается, и в окошке консольном данные бегут

Цитата:

как можно очистить историю сохраняемых профилей?

только вручную в freearc.ini

Sig666
egor23

предполагаю, что дело в GUI-шности - код, запускающий внешние утилиты с stdin/stdout видимо написан так, что он корректно работает только в консольных прогах. как-нибудь посмотрю

Bulat_Ziganshin
Благодарю за наводку! Разобрался, редактировать ini-файл нужно тот, который лежит в c:\Users\UserName\AppData\Roaming\FreeArc\ , я пытался править тот, что в Program Files... Сейчас настрою под себя, скопирую в другое место, что бы при запуске батника скидывать настройки, а не править каждый раз "ручками".

Цитата:

плин у arc распаковка не работает
зато динамик PC заливается, и в окошке консольном данные бегут

то работает распаковка, а то не работает
....
замечено

при распаковке, если есть файл с таким же именем, то выдаётся запрос на перезапись, то распаковка проходит нормально, а если нет, то динамик пищит...

Добавлено:

Цитата:

а меня FreeArc обидел,

arc тоже обижает

А мможна сделать в freearc когда создаешь архив с внешними компрессорами то они добавлялись в архив а при распаковывании добывались около архива и тогда распаковывался сам архив. В версии 0.70 в архиватор будет интегрирован среп?

Цитата:

замечено

при распаковке, если есть файл с таким же именем, то выдаётся запрос на перезапись, то распаковка проходит нормально, а если нет, то динамик пищит...

у FreeArc такой фокус не прокатывает

Добавлено:

Цитата:

замечено

при распаковке, если есть файл с таким же именем, то выдаётся запрос на перезапись, то распаковка проходит нормально, а если нет, то динамик пищит...

кстати, если у 7-zip накосячишь с ком.строкой, то помимо всего, есть такое сообщение
ERROR: Идет закрытие канала.
терзают смутные сомнения, а не требуется ли "время" на открытие\закрытие канала.

Stalqer
1. Прочитай FAQ по FreeArc (4-й вопрос)
2. Прочитай Планы дальнейшего развития (Версия 0.75)

Добавлено:
Bulat_Ziganshin

Цитата:

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

Новый вариант:


1508 Queue operations across multiple FreeArc copies=Эта опция позволит поочередное выполнение\nопераций (упаковки, распаковки, восстановления\nархива и т.д.) даже при одновременной работе\nнескольких копий FreeArc. Таким образом, они не будут мешать друг другу полностью использовать\nресурсы компьютера и, как правило, выполнятся\nбыстрее.

Bulat_Ziganshin
может подскажешь что с моим архивом не так ?
вроде всё верно сделал, да и в логе всё впорядке вроде.

slech
не вижу криминала. надо попробовать самому. а ты залей архив на rghost

Bulat_Ziganshin

Спасибо за хорошую работу! Единственное opensource-решение, позволяющее настроить необходимый и достаточный бэкап за определенный период. Разностные архивы 7zip куда хуже в этом плане, потому что растут.

Разрабатывая бэкап документооборота, столкнулся со странным (для пакетной работы) поведением консольной версии 0.666. Так, некоторые ошибки ключей не фиксируются в логе, задаваемом --logfile, а выводятся в stderr, после чего arc возвращает скрипту код 1 (предупреждения)

Например, отсутствие файла исключений, задаваемого ключом -x@filename

C:\BACKUP>arc a bak bak -x@arc
arc.EXE: arc: open: does not exist (No such file or directory)

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

Задание времени ключом -ta приводит к ошибке

C:\BACKUP>arc a bak bak -ta >> arc
arc.EXE: user error (Time.toClockTime: invalid input)

C:\BACKUP>arc a bak bak -ta0 >> arc
arc.EXE: user error (Time.toClockTime: invalid input)

хотя в описании сказано, что недостающие знаки добиваются нулями, то есть ожидается поведение как при -ta00000000000000, иными словами, с начала времен

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

FreeArc0,67а (17 ноября 2010) Метод сжатия –mex5 Особенности Улучшения
Метод сжатия –mex5 полностью выглядит так:
rep:128mb+exe+delta+4x4:i0:lzma:4mb:normal:bt4:128, $obj => rep:128mb+delta+4x4:i0:lzma:4mb:normal:bt4:128, $text => dict:64mb:80%:l8192:m400:s100+lzp:64mb:90%:65:h22:d1mb+4x4:b7mb:ppmd:8:96mb:c7mb, $wav => tta, $bmp => mm+grzip:8mb:m1:l2048:h15:a
Memory for compression 740mb, decompression 751mb, cache 16mb
(Требования к памяти зависят от процессора, в данном случае Процессор i3-530, 2 ядерный, 4 поточный, Win7 32-разрядная, ОЗУ 4 ГБ)

1)    Основной способ сжатия: rep:128mb+exe+delta+4x4:i0:lzma:4mb:normal:bt4:128
2)    Предлагаю его модифицировать в группах exe и $obj, добавив :h32m:
rep:128mb+exe+delta+4x4:i0:lzma:4mb:h32m:normal:bt4:128
В моих тестах степень сжатия и требуемая память оставались такими же, а скорость сжатия увеличивалась примерно на 10%
3)    Для сравнения сжатие всех данных одним методом, без деления на группы:
-mrep5+exe+delta+4x4:i0:lzma:4mb:h32m:max (что полностью записывается как
-mrep:128mb+exe+delta+4x4:i0:lzma:4mb:h32m:normal:bt4:128)

Результаты сжатия этих трех вариантов, для одного из тестов, а именно http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=60#16 или http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=720#20
Метод  time: cpu  time: real  Размер архива    Memory Memory
for compression     for decompression
1)     1022 с    281,1 с    1 283 998 727    740mb    751mb
2)     938 c    260.1 c    1 283 998 653    740mb    751mb
3)     969 c    249.0 c    1 282 608 960    460mb    176mb
К слову, сжатие без деления на группы получилось самым быстрым, самым сильным и требует меньше всего памяти.

Подробности
Справедливы только для метода сжатия lzma:…:bt4 (или что то же самое lzma:…:max)
Сокращенная запись lzma:4m означает lzma:4m:h8m
Зависимость от параметра «:h» (что он означает – знает только Булат?)
для сжатия по методу вида -mrep5+exe+delta+4x4:i0:lzma:4mb:h32m:max

Метод     time: cpu    time: real    Размер архива    Memory Memory
for compression    for decompression
4m:h64m:max      961 с    251,4 с    1 282 608 956    588mb    176mb
…:h32m:…     968 c    249.8 c    1 282 608 960    460mb    176mb
…:h16m:…     995 c    259.2 c    1 282 608 850    396mb    176mb
…:h8m:…     1054 c    270,8 с    1 282 609 260    364mb    176mb
…:h4m:…     1153 с    295,0 с    1 282 613 168    348mb    176mb
Результаты тестов повторялись на различных данных.

Общая характеристика метода –mex5
Метод не отличается эффективностью, и если только позволяет объем ОЗУ, лучше пользоваться более эффективными методами –mex6, –mex7 или –mex8.

Булат
Просьба оценить мои результаты для использования в FreeArc.

:h означает размер хеша (на каждый тред сжатия, их в твоём случае создаётся 4). посмотри использование памяти в taskman

потребление памяти согласно показаниям самого freearc не изменяется потому, что текстовое сжатие настроено на использование ещё большего объёма памяти:

C:\!\FreeArchiver\Tests>Arc.exe -mrep:128mb+exe+delta+4x4:i0:lzma:4mb:normal:bt4:128 a a -di
Memory for compression 364mb, decompression 176mb, cache 16mb

C:\!\FreeArchiver\Tests>Arc.exe -mrep:128mb+exe+delta+4x4:i0:lzma:4mb:h32m:normal:bt4:128 a a -di
Memory for compression 460mb, decompression 176mb, cache 16mb

C:\!\FreeArchiver\Tests>Arc.exe a a -di -mex5
Memory for compression 740mb, decompression 751mb, cache 16mb

Добавлено:

Цитата:

lzma:…:bt4 (или что то же самое lzma:…:max)

это не одно и то же. max=normal:128

Есть файл весом 5,17 гб. Как его можно разбить на 2 или три архива?

Ololo77

Цитата:

На сегодняшний день в FreeArc отсутствуют следующие возможности, доступные в RAR и 7-zip: поддержка многотомных архивов, 64-битная версия, поддержка расширенных атрибутов NTFS, BCJ2, сегментация данных.

паковать в 7z например.

Да, понимаю.
По памяти мы чуть-чуть выйдем за текстовое сжатие при -mrep5+exe+delta+4x4:i0:lzma:8mb:h64m:max

Метод time: cpu time: real Размер архива Memory Memory
for compression for decompression
8m:h64m:max 999 с 256,1 с 1 276 886 566 748mb 212mb

И это еще эффективней.
Только тогда всю линейку надо сдвигать, так как -mex6 использует подобный режим (а точнее, хуже этого).

Про max=normal:128. Насколько я понимаю, normal - это не bt4. Тогда уж max=normal:bt4:128
(Со всем приходится долго разбираться, поскольку четких описаний нет).

slech
Спасибо, буду пробовать.

Извините за мою лень, но не могли бы подсказать как сжимать при помощи FreeArc данные, поступающие из stdin ?
Конкретно требуется:
flashnul 2 -S - | arc.exe "что еще не пойму"
т.е. хочется забекапить данные с физического диска 2, сжав их freearc-ом.

SREP 2.93 alpha:

* compression: unrolled internal loop, unrolling factor is defined by -a option
* compression: I/O and md5/sha1 tasks are offloaded to separate thread
* compression: memory-mapped file used for match checking
* compression: now memory usage printed exactly

Compression made 2-3x faster compared to srep 2.0

Memory usage was also increased (and compression factor decreased a tiny bit). You may restore them back to old values with -a1 option

Memory-mapped files usage may be supressed by -nommap option. Please experiment with it and say whether it may improve speed in some situations

Bulat_Ziganshin

Цитата:

* compression: unrolled internal loop, unrolling factor is defined by -a option
* compression: memory-mapped file used for match checking

а можно поподробней? А то не понятно ни принципа, ни смысла)

Цитата:

* compression: I/O and md5/sha1 tasks are offloaded to separate thread

а что ж декомпрессию стороной обошел?)

З.Ы. Спасибо за релиз)

"Извините за мою лень, но не могли бы подсказать как сжимать при помощи FreeArc данные, поступающие из stdin ? "

flashnul 2 -S image ; arc.exe a image image...

Типа так?

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

Цитата:

а что ж декомпрессию стороной обошел?)

я и так со сжатием достаточно повозился


Цитата:

а можно поподробней? А то не понятно ни принципа, ни смысла)

можешь посмотреть исходники, а ещё лучше - патчи в svn

1. процесс сжатия для каждого байта проверяет, не был ли похожий 512-байтный блок раньше. эта проверка требует обращения к памяти (мимо cpu cache), а это очень дорогая операция - считай мы 5 тактов тратим на все вычисления и 50 на эту проверку. я использовал технику, которая позволяет сократить число этих проверок в 2-16 раз за счёт использования большего объёма памяти

2. одна из причин медлительности сжатия - чтение из сжимаемого файла небольших блоков данных в случайном порядке, что приводит к OS-level call. вместо чтения я отображаю весь файл на память и дальше просто сравниваю участки памяти

KurshakovIS
К чему лить воду?

Вопрос БЫЛ вполне конкретно озвучен:
может ли FreeArc сжимать данные поступающие из stdin ?


Код: arc a x -si
arc: Cmdline.hs:(829,23)-(832,59): Non-exhaustive patterns in case

Bulat_Ziganshin

Цитата:

вместо чтения я отображаю весь файл на память и дальше просто сравниваю участки памяти

а что если при распаковке создать нечто вроде "списка" с записями типа 1, 2, 3 ,
где 1) - здесь оригинальные данные, к которыйм еще нет совпадений
2) - здесь данные повторяют оригинальные данные из 1)
3) - здесь часть данных (или пару байт) из 1)

и при прочтении списка сразу знать, что нужно прочитать, а потом по этому "списку" в памяти "формировать" готовый участок памяти, пускай даже блоками по 8Мб, типа 1122121232333, который позже брать и писать в файл.
Извини, если недоходчиво изложил идею