> Ну как бы в итоге все состоит из времени чтения + времени распаковки, и оптимальность сочетаний не константа и варьируется в зависимости от кучи факторов.

Мне лично задержки не критичны и большая часть пользовательских данных мне видится похожей на man'ы, которые в .gz и в основном пылятся. А LZ-алгоритмы это для чего-то типа zswap, траффика и динамичных игр, т.е. где в идеале никакой компрессии нет, но нужно как-то обойти ограничения по объему или пропускной способности. И вот в таких сценариях логичнее было бы брать начиная с самого быстрого, то бишь lz4, а если затык останется, то пробовать шаманить с уровнями сжатия или брать lzo.

> На самом деле это очень многофакторное и зависит от ряда соотношений (например мощь CPU и скорость RAM vs IO) и по факту лучше бенчить именно у себя на именно интересных кейсах.

Подход а-ля Gentoo конечно дает плоды, и при желании можно заморочиться, но бенчить все подряд времени не хватит, а качественных и актуальных замеров очень мало. А так, если есть результаты на разном железе и для разных данных, как на том же Squash Compression Benchmark, то по ним вполне можно делать выводы. Хотя я уже понемногу пилю свои бенчмарки, с упором на то, что лежит в /usr - шрифты, иконки, маны, бинарники и т.д..

> ИМХО LZO в целом поплотнее LZ4, а в ФС с требованием на рандомный seek и потому лимитом на размер блока zstd  негде на полную разогнаться.

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

> И таки LZO побыстрее zstd во многих случаях и инициализация дешевле: поток LZ4 и LZO можно распаковывать с места в карьер, zstd и zlib в этом более навернуты и надо состояние entropy coder еще инитить.

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

> Да и на практике решаемая, только это как компрессия с супер-большим словарем и потому оперативы немеряно жрет и CPU грузит весьма прилично. И хотите ли вы это все вот именно в момент записи - очень отдельный вопрос.

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

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

Флешки к сожалению приходится держать в exfat / ntfs, а btrfs даже Ventoy не понимает. И как же я пожалел, что давно создал exfat раздел на ЖД под файлопомойку - прав доступа нет, преаллокации нет, уменьшить - хрен. Лучше уж ntfs, если нужен доступ из под винды и линукса. А теперь и вовсе может быть, что btrfs на эту роль подходит лучше, т.к. под винду есть драйвер, который ставится в пару кликов.

> Или снапшоты. Почти как виртуалка.

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