> Пожалуй да, хоть zstd:1 неожиданно хорошо себя показал в плане сжатия,Zstd делал тот же кодер что LZ4, это творение Cyan'а. Технически это "что-то типа LZ4" но - мощнее, жирнее и с entropy coder за ним, на основе новомодного ANS от Jarek Duda.
По своему забавное комбо. Потому что как минимум точно может по степени сжатия дать мастеркласс gzip'у, на топовых уровнях почти садясь на хвост грандам типа LZMA (который слоупок) и Brotli (этот читерит, и "в чистом виде" не так уж крут) - но при этом даже быстрее в распаковке. Смысл брать gzip при существовании zstd минимальный, но видимо уже были тома с вот этим, не обламывать же их?!
LZ4 технически в общем случае быстрее за счет отсутствивя entropy coding за ним. Но и жмет он хуже в результате. Так что оптимальность штука многогранная.
Уровень сжатия zstd актуален если много ЗАПИСЫВАТЬ и быстро: на высоких уровнях да с хилым процом это может в проц упереться, недогрузив девайс на ЗАПИСЬ. Распаковка в разы быстрее и ее скорость не сильно зависит от поюзаного уровня.
Врядли baldurs gate много ЗАПИСЫВАЕТ. Зачем гамесе много записывать? А на распаковку - там еще зависит жатые ли у него ресурсы или нет. Некоторые гамесы сами сжатые типа-архивы юзают, им с сжатия в ФС мало что перепадет. А если ассеты не сжатые тогда сжатие что-то отыграет.
Что до XFS сам по себе ничего не дедуплицирует. Но с неких пор его таки научили в рефлинки. И можно сделать "thin" копию которая изначально ссылается на блоки оригинала а дальше по мере расхождения обеспечивает абстракцию что это независимые файлы. Изначально фокус btrfs, но XFS а недавно наконец и ZFS этому научили. Сабж тоже это вероятно или умеет или скоро будет уметь, куда оно денется, для cow стыдно такую семантику не уметь. В btrfs также можно и оффлайн-дедупнуть идентичные файлы тулсами типа jdupes. Хз, может уже и на XFS работает если оно заимплементило "same extent ioctl", для XFS я это не проверял. После их демарша с выносом v4 в obsolete без путя конверсии в v5 я их разобрал и btrfs'ом сделал, коли уж крушить так пусть тогда и cow полноценный и управление местом по первому классу. Они вон scrub и автопочинку до сих пор осилить не могут, да и многодевайсность там это боль.
> zstd:6 оказался хорошим выбором, не заметил каких-то заметных просадок в еле
> идущей на этом ноуте Baldur's Gate 3 (а я еще и сейвскамер).
Да я и сам zstd местми юзаю на btrfs. Главное /boot в zstd не сжать случайно если grub старый и без поддержки zstd, а то тот очень обижается на "unknown compression algo". Каким-то дистрам актуально у каких-то он уже zstd умеет.
> это пожалуй рекордсмен по количеству операций чтения, и постоянное разжатие это
> повышенное использование процессорного времени.
XFS вообще довольно интенсивная по метаданным штука и идея разложить на него пачку репов git как по мне довольно спорная. У меня такое ощущение что даже btrfs его заметно делает на таких нагрузках. При том умея кучу продвинутостей.
> проблема, что она неадекватно распухает от метаданных. Так что в обоих
> случаях может оказаться, что игра не стоит свеч.
Да черт знает, от штук размером с линукскернел вроде не так уж и распухает, я еще рефлинкаю билддиры на оригинала и они и копируются "очень быстро" и места жрут сильно меньше суммарного веса.
> Может быть даже есть смысл вместо btrfs смотреть в сторону zfs, ведь
> по идее ноутбучная DDR память довольно энергоэффективная, а сама zfs более
> продвинута в плане размещения данных на диске.
ZFS был самым первым - с фига ему эффективным быть? Это даже еще не экстентный аллокатор, какой-то недопилок с "блоками переменных размеров" как максимум. Поэтому и затыкают его скорость работы гигазами рамы, рамдиски то быстрые. Но с подпором ...цать гиг опертивы что угодно - быстрое. Я называю его "первый блин комом". На уровне структур ЭТОМУ нет причин быть быстрым.
Btrfs появился позже и их поэтому хватило на нормальные экстенты, tail packing, хранение мелких файлов сразу в деревьях (что быстрее, особенно на механике, не надо головы гонять хз куда, данные сразу доступны). Ессно свои проблемы тоже есть. Но актуальны больше на многодисковых конфигах и особенно желающим продвинутостей типа RAID5/6 и проч. На самом деле крутой и фичастый дизайн, но это же и усложняет доведение до ума в мелких деталях. Самый заметный минус - не делался под "низкий оверхед" с самого начала, на суперскоростных SSD все же заметно.
Сабж - дизайнился еще позже. И потому пытается вобрать лучшие черты всех предшественников. Обойдя их недостатки. Серебряных пуль - не бывает. Но в целом - ключевые решения btrfs напоминают но с вниманием к оверхеду и скорости, и вот еще иерархические хранилки, это конечно не для тех кто на разделы что-то нарезает, а для тех кто несколько девайсов хочет, сочетая сильные стороны разнородных устройств. Есть скажем гибриды SSD+HDD где SSD буферизует запись, а потом неспешно сливается на HDD. Сабж делает сие уже софтварно - из того что есть - и подконтрольно владельцу, не требуя гибридных устройств и давая больше контроля над этим аспектом. По своему круто. Если есть HDD и SSD можно получить почти скорость SSD и емкость HDD. Если правильно нарулить вон то. Нюансы конечно будут. Но все же.
