> Мне лично задержки не критичны и большая часть пользовательских данных мне видится
> похожей на man'ы, которые в .gz и в основном пылятся.

Ну как, в случае быстрой SSD'хи на умеренном проце скорость записи zstd может заметно обвалить. А там еще чексумы считать надо, том тоже на скорость. В этом месте LZ4 и LZO деланные под "реалтаймное сжатие" получают пойнт.

> А LZ-алгоритмы это для чего-то типа zswap, траффика и динамичных игр,

Ну вообще я zram и с LZ4 или ща LZO+RLE модно у них стало. Довольно хорошее, кстати, комбо. RLE уменьшает тупняки на сжатие избыточных последовательностей коих в раме есть, в паре с LZO довольно хорошо жмет, там вопрос в том что либо сожмется минимум в 2 раза, и тогда профит, или нет - тогда зря сожрали ресурсы: там округление до страницы ради скорости. Можно 2 в 1 паковать. Или опциональный 3 в 1 (если данные позволили, конечно). Там рыхлость LZ4 икается больше: если 2x сжатие не вышло, проц тратили вообще зря.

...и в результате OOM с таким "свопом" без выгрузки в файлы/разделы - это секунд 5 просадки перфоманса, а потом OOM killer вынесет обжору. И никаких тупняков минутами как с свопом на дисках.

> т.е. где в идеале никакой компрессии нет, но нужно как-то обойти ограничения
> по объему или пропускной способности.

Я в случае zram ничего не обхожу - я неспешно и в фоне оффлоажу оперативу от "cold" данных в их сжатый вариант, ну оно и выигрывает 2-3x от размера выделенного на zram региона. Даже мелкороутеру нормально - и будучи ram2ram сильно меньше причин тормозить. Если сжатие быстрое.

> И вот в таких сценариях логичнее было бы брать начиная с самого быстрого, то бишь lz4,
> а если затык останется, то пробовать шаманить с уровнями сжатия или брать lzo.

На момент дизайна btrfs в ядре lz4 еще не было. А потом... см. про бутлоадер например. Хотя вон у кента, да и btrfs zlib так то тоже есть, не прокатывать же обладателей томов.

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

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

> по ним вполне можно делать выводы. Хотя я уже понемногу пилю
> свои бенчмарки, с упором на то, что лежит в /usr - шрифты, иконки, маны, бинарники и т.д..

Хе, забавно. Ну и да, вот что-то такое неплохо жмется так то.

> 128 КБ это не такой уж и маленький блок, я пощелкал графики
> и для файлов даже поменьше этого блока - в принципе динамика не сильно отличается.

Ну и не такой уж большой - на более жирных блоках скажем zstd vs zlib будет сильнее в пользу zstd. А на файлухе это менее выражено, 32 кил словарь не такая уж трабла если максимум 128К на все.

И да, лидеры и аутсайдеры могут меняться от задачи. Я лю с simple LZ развлекаться. Скажем то что рулит на мелких блоках не обязано на бошьших рулить. И наоборот. Многое зависит от деталей формата потока vs макс словарь vs как оно match(offset, len) кодирует и есть ли у формата бонусы. У LZ4 неудачное (по степени сжатия) кодирование больших чисел, на хорошо жмущихся данных он заметно проигрывает хоть тому же LZO, у коего более продвинутый и компактный формат, в LZ4 в угоду скорости в жертву принесено вообще совсем все. Он вообще сильно плотно жать не может даже если данные хорошо жмутся, формат потока лимитирует. Длинный match или match на большом смещении требует куда больше байтов на кодирование чем в даже большинстве иных "simple LZ". За это ratio временами таки хромает.

> Ну да, это разные весовые категории, но zstd в своей лидер, а
> lzo - середнячок.

А LZ4 это довольно экстремальный случай где ради скорости даже формат потока довольно дурной и в плотное сжатие он за это совсем не умеет, на уровне формата потока прямо. Так что есть ряд не очень известных перепевок где народ пытается жать поплотнее, не пролюбив особо скорость распаковки. Некоторые штуки при том на именно мелкие блоки специализируются. Их характерных представителей - lzsa, zx0 и тому подобное. Они не на это ориенитированы но с учетом ориентации на мелкие блоки возможно это не так уж плохо и для ФС было бы.

> Вот клонирование жирной монорепы - это тот случай, когда придется ждать, а
> потом еще и скорее всего npm install делать. RAM и CPU
> в это время прохлаждаются - любимый VS Code или IntelliJ Idea
> еще не запущены, а Dota 2 не может загрузить все ваши
> 32 ГБ оперативы и 16 ядер Threadripper'а. Так что вот он
> момент, чтобы отжать кусок RAM'ы и начать онлайн-дедупить.

Ну тогда в случае какихнить bees и пустить их в "околореалтаймном" варианте, там наверное нормально. И это... т.к. файлуха всегда активна, она это все время хочет жрать.

> Флешки к сожалению приходится держать в exfat / ntfs, а btrfs даже Ventoy не понимает.

Ну мне на ventoy пофиг, для загрузочной флехи я делаю условно "инсталл моего десктопа на флеху". А если занесло на совсем чужой комп, есть стебная штука - WinBTRFS :). Не буду настаивать что это всегда и для всех, но...

> И как же я пожалел, что давно создал exfat раздел на ЖД под файлопомойку - прав
> доступа нет, преаллокации нет, уменьшить - хрен.

Последний писк 90х прошлого века...

> Лучше уж ntfs, если нужен доступ из под винды и линукса.
> А теперь и вовсе может быть, что btrfs на эту роль подходит лучше, т.к.
> под винду есть драйвер, который ставится в пару кликов.

Ну да. WinBTRFS называется. И NTFS лично меня вымораживает скоростью работы с большими иерархиями. Если туда расжать что-то размером с линукскернел... ммм... не сильно то оно лучше ExFAt'а ощущается.

>> Или снапшоты. Почти как виртуалка.
> Мне бы их лет 15 назад, когда я обвешивал модами Обливион без
> всяких мод-менеджеров.

Да я бы тоже не отказался так то - чтобы cp --reflink'ать например образа винчей с которых файло восстанавливаю. Ну тут уж упс. Даже, вот, прикольные алгоритмы сжатия для мелочи появились - тадам - сильно опосля того как они были сильнее всего нужны.

"Опыт это такая штука которая у вас появляется сразу после того как он был нужен" :)