> Вчера таки еще разок заглянул на страничку Compression в доке btrfs, и
> оказывается lz4 у них нема, только lzo, так что кажется я
> вспомнил, почему именно выбрал zstd:1.

LZO по смыслу похож на LZ4, тоже скоростной 1-компонентный алгоритм, с прицелом на скорость распаковки. LZ4 не стали встраивать потому что слишком похожие по свойствам алго, и ради чего возиться тогда?! На момент дизайна btrfs LZ4 в ядре еще не было, взяли похожий LZO.

Более новые дизайны берут LZ4 т.к. он немного резвее, а степень сжатия при желании скорости все же вторична. Но в целом сравнимые алго подвида "simple LZ".

> А так по методам сжатия полностью согласен, для меня есть только lz4,
> zstd и понемногу уходящий старичок gzip, а всякие xz, bzip2, brotli
> слишком медленные даже на разжатие.

Ну дык. Xz это LZMA на стероидах. Жмет круто, но даже скорость распаковки - в разы хуже. Им пользуются когда надо до последнего байта экономить. Как вон тот uboot с вебмордой для для TPLink-ов. Там оно либо втиснется в 64 кил регион со ВСЕМ, либо нет, а больше некуда. Вот и приходится хардкорить, даже если и дольше стартует это лучше чем никак. В менее радикальных случаях скорость его распаковки так себе, даже на initrd - от него заметная на глаз задержка при старте на распаковку, например.

А бротли сильно оптимизирован на вебпаги, мухлюя с встроенным предзагруженным словарем. Улучшает сжатие вебпаг - ценой хранения надерганого из них словаря 120 кило в либе. Так что можно сразу ссылаться на совпадения еще не вгрузив данных. А если не вебпага, тогда фокус может и не прокатить и сам по себе он "чуть помедленнее и чуть хуже жмет чем zstd". Поэтому кроме браузеров и вебсерверов мало кем используется.

> Причем даже zip архивы удобнее, DEFLATE все-таки хорошие цифры показывает.

У deflate словарик склерозный, 32 кило. На больших повторяющихся файлах он не увидит совпадение через мегабайт - и может основательно проиграть на этой почве. По скорости распаковки хуже в основном за счет Huffman vs ANS в второй части. ANS это более забористая абстракция, сочетающая плюсы arithmetic coding в сжатии с скоростью даже лучше huffman, за что и используется в новых кодеках. Эпл что-то тоже делал и сорц даже публиковал, но zstd мастеркласс им дал, потому что Cyan (автор LZ4) и Jarek Duda (создатель ANS) в 1 команде могут порвать на пару много кого, ну zstd и зарулил много кого. Facebook кроме этих 2 и еще пару приличных алгоритмистов нанял, уделать такую тиму нелегко.

> F5 - и пошла запись, правда это обычно объемы небольшие, но в
> процессе игры.

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

> на 12 ГБ, т.е. почти на 10%. А так, многие игры
> перестали жать ресурсы и постоянно подгружают какие-нибудь текстуры с диска,

Ну тут все зависит от конкретики. Бывает и так что ассеты 50/50, т.е. часть сжатые, скажем PNG какой или текстуры пакованые, а часть - жмется.

> tar, а тупо держат каждую текстурочку в виде отдельного файла -
> интересно как такие пациенты себя поведут.

Им в целом перфоманс файлухи актуален. В этом смысле - я бы их на XFS складывать не стал, тот с кучей файлов работает "не очень". А в остальном EXT4/btrfs/f2fs/....  в принципе не особо тормозят с разлапистыми иерархиями.

> Но игры обычно упираются в GPU, а в CPU по идее должно оставаться немного "воздуха" на
> незатратное разжатие, так что игоры я буду жмать.

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

> Ну тут просто надо остановиться на чем-то одном, а xfs (v5) вроде
> пободрее мейнтейнят и inode он выделяет динамически, значит по идее не
> должны внезапно закончиться. С дедупликацией только я так и не поигрался,
> но как-нибудь создам 2 раздела с xfs и btrfs, гляну чего
> можно добиться для тех же исходников ядра. Особенно интересно, можно ли
> добиться online дедупликации на моменте git clone.

Совсем онлайн нету - и большой вопрос хотите ли вы именно это, именно так. На энтерпрайз файлопомойке то претендентов на RAM и CPU нет, можно все сожрать. А на более обычном компе... ближайшее к этому наверное прога "bees". Некая приблуда строящая базу потенциальных дупов, в том числе и инкрементально могет если в фоне держать. Изначально для btrfs делано но может и с XFS работает, если уж оно рефлинки научилось то может и в "same extent" смогет. Лично для XFS не проверял.

>> Я называю его "первый блин комом". На уровне структур ЭТОМУ нет причин быть быстрым.
> Вот этого не знал, я думал это btrfs долгое время был вообще
> непригодным к использованию и до сих пор легко ломается,

Ну как, btrfs это довольно большой и сложный дизайн. Его отладка заняла время. И до сих пор RAID5/6 имеет свои нюансы. Для RAID5 частично починеные, 6 еще нет. Если они нужны, читать мануал и думать окей ли оно вот так. И метаданные в RAID1 лучше. Сильно безопаснее. Но он технически более поздний чем ZFS и сделан с оглядкой на него - и попытками обойти неудобные места. Более прозаичные кейсы типа RAID1 вполне юзабельны как по мне. И в целом у дизайна больше задел на будущее. Разопрется ли кто когда ВСЕ его возможности раскрыть - вопрос номер два. Скажем теоретически на btrfs можно разным файлам разную схему хранения давать. Не все файлы одинаково ценны. Практически - ну там и без этого наворотов хватает и слабых мест.

> а zfs сразу бодро встал и пошел за счет удачного дизайна.

Ага, конечно. Его тоже так то отлаживали дофига, своих грабель у него тоже есть, scope у него изначально меньше - энтерпрайзные файлохранилки, btrfs более универсальный. А технологии тогда были менее развиты. Так что максимум на что их хватило это блоки переменного размера, сильно меньше нормальных экстентов, значит оверхеда в метаданных больше. С чего этому быстрому быть только фаны марки и знают. А с десятками гиг буферов что угодно "быстрое".

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

Бенчмарки бывает довольно сложно интерпретировать - да и насколько оно похоже на то что вон там актуально - как повезет. Самое очевидное - cow'ать большие нагруженные базы неважная идея. Но это надо не всем и не всегда, а btrfs умеет для этого no-cow, становясь чем-то типа EXT4 для таких файлов. Но и все плюсы cow типа снапшотов и чексум при этом в ауте. Zfs и это не умеет и постепенно может зафрагментиться в хлам. А дефрагера у него как я помню совсем нет.

На самом деле лучше всего попробовать самому и что понравится и пойдет под требования то и оставить. Бенчи это прекрасно а юзать все же не автору бенчмарков.

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