insorg
Platinum Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
EugeneRoshal
Цитата:| -mcx -m5 с соответствующим словарем это максимум возможного без потери совместимости на сегодняшний день. |
Принято. Хотя, слегка удивлён, что никаких скрытых параметров или ещё какой хитрости не осталось...
С другой стороны, это и хорошо, что их нигде искать не нужно, как в том же FreeArc, где "с наскока" одним параметром не отделаешься.
Цитата:| Посмотрел в исходники RAR4. Для -m1..-m5 используются 4:5, 4:10, 4:15, 6:20, 8:25 соответственно. |
Спасибо. Хотел было попросить это добавить в доки...
А потом вспомнил про "отказ" от rar4 в семёрке. Может, не стоит рубить его хотя бы в консольной версии?
Цитата:| Да, сейчас FSCTL_SET_COMPRESSION вызывается по окончании распаковки. Возможно, в следующих версиях мне надо будет проверить, насколько заметен выигрыш в итоговой скорости при вызове FSCTL_SET_COMPRESSION сразу после создания файла. Если выигрыш существенен, можно будет попробовать поменять код. |
Выигрыш будет как минимум из-за отсутствия надобности два раза писать данные - сначала обычно, а потом жато. Особенно если они сами по себе содержат много нулей (типа образов iso, vhd...) и отлично жмутся. Следовательно даже если "не дожидаться", то количество дисковой работы можно уменьшить на ровном месте.
Тем более, что фрагментация всё равно будет в любом из вариантов, она здесь неизбежна.
Добавлено:
pikorembo
Цитата:| Тогда я обнулил содержимое файла (с сохранением атрибута "сжатый") и повторил тестирование. Результат не изменился, а это значит, что данный способ является наиболее быстрым по скорости записи и наиболее щадящим для диска. |
Всё верно. Именно так можно и уменьшить количество записей ценой фрагментации. Для SSD это иногда допустимо, особенно - для старых, которые не умеют жать данные контроллером и даже поток нулей "честно" пишут на флеш.
Добавлено:
EugeneRoshal
Цитата:| Непонятно, откуда в варианте 4 столь сильное проседание скорости. В нем мы просим систему сжать уже сжатый файл. По идее, повторный запрос на сжатие должен быть просто проигнорирован. |
Там всё верно и в полном соответствии с поведением штатной compact /c, которая при явном вызове её для "уже жатого" будет принудительно пережимать файл, вне зависимости от его начального состояния. Для неё это нормально и позволяет исправить ситуацию с частично недожатыми или частично неразжатыми файлами, что может получаться при перезагрузке посреди процесса работы compact, например.
Добавлено:
pikorembo
Цитата:
Цитата:| Непонятно, откуда в варианте 4 столь сильное проседание скорости. |
Тут нет ошибки. Действительно, проседание скорости в 3,1 раза по сравнению с вариантом №3. Не знаю, с чем это связано. |
Особенности работы compact /c, только и всего. Потому что понятие "сжатый ntfs" бывает разное. Вон, в десятке и новее одних только вариантов в виде сжатого потока (параметр /exe, /exe:lzx, и т.д.) целая куча. Да и "старый" вариант на каждом отдельном файле может быть в разном состоянии в конкретный момент времени. Где-то процесс не закончился, где-то рано начался и потом его отменили, и т.д., потому нет ничего страшного и удивительного в том, что утилита позволяет дать повторную команду того, что уже выглядит сжатым (ведь, реально ли оно сжато "полностью" - вопрос отдельный). |
для Буркина-Фасо и половины Африки. 
