Очевидно, что быстрее без компрессии.

Нарвался вот на такую ссылку, но ссылка на тест умерла:

http://www.linux.org.ru/wiki/en/Reiser4#%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%...

It depends.

>Очевидно, что быстрее без компрессии.

Очевидно, вы не правы. Результат сильно зависит от характера данных. Если легко сжимаются, то со сжатием будет быстрее.

Ни разу не очевидно. Достаточно рассмотреть крайний случай - бесконечно быстрый проц и бесконечно медленный диск

Ладно, как можно протестировать рандомный выбор данных с раздела?

...
Создав раздел с рандомным (или не очень) содержанием из файлов с рандомным содержимым -- практически несжимаемые данные.
Создав раздел с тем же содержанием из файлов с нулевым содержимым -- идеально сжимаемые данные.
Натравить tar на дерево в разделе с сохранением в /dev/null.
Повторить для раздел{а,ов} с компрессией.
...
Поделиться информацией...

> Ни разу не очевидно. Достаточно рассмотреть крайний случай - бесконечно быстрый проц и бесконечно медленный диск

и как коррелирует диск и процессор ? Очевидно же, что должен быть бесконечный объем оперативной памяти с неограниченной шиной.

Очевидно, что зависит от характера задачи. Если она будет упираться в производительность процессора - то быстрее будет без сжатия. Если в скорость жосткого диска - быстрее будет со сжатием.

> http://www.linux.org.ru/wiki/en/Reiser4#%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%.. .
>Нарвался вот на такую ссылку, но ссылка на тест умерла:

FIXED http://web.archive.org/web/20070620025139/linuxhelp.150m.com/resources/fs-ben...

> Что быстрее будет для /usr? lzo, gzip или использование без компресии?

gzip или lzo будет быстрее. Что именно, зависит от содержимого файла и скорости работы диска. Правильная ссылка на бенчмарк выше.

Да, это тоже. В любом случае - никакого "очевидно".

А как с фрагментацией? На нтфс сжимаемые данные например ЕМНИП очень сильно фрагментируются.

> А как с фрагментацией? На нтфс сжимаемые данные например ЕМНИП очень сильно фрагментируются.

Хреново и наверное не лучше чем на нтфс. KRON73 об этом говорил в тестах, когда разговор шел о частоизменяющихся данных в /var/lib/portage/.

Хотя там и без сжатия появлялись хорошия тормоза.

>На нтфс сжимаемые данные например ЕМНИП очень сильно фрагментируются.

Я помню на втором курсе мне понадобилось лишних 200 Мб на забитом под завязку 860Мб HDD. Денег на апгрейд не было, возможности удалить часть файлов тоже. Пошел на крайние меры и решил испытать Drvspace из 95-й Винды, мысленно попрощавшись с данными. И оно сработало(!) и дало лишних 300Мб, при этом перформанс даже немного улучшился. Никаких проблем не было даже тогда, а с тех пор прогресс наверно продвинулся. Правда, теперь желания рисковать данными почему-то нет.

Drvspace вроде создавал дополнительный диск и образ сжатого диска помещался на несжатом. Здесь же все на уровне ФС

Lzo1. Nocompress в работающем виде я не видел, а пара процентов разницы сжатия дают преимущество gzip'у только в нём - не в скорости декомпрессии. Я бы назвал 10-15% нагрузки на каждое ядро "лёгким" оверхедом, ибо его заметить сложно.

И да, в скорости чтения проигрывает только tmpfs, насколько я могу судить :)