> Я смотрю в первую очередь на скорость разжатия, все-таки данные пишутся один
> раз, а читаются потом всегда. А разжатие у lz4 заметно быстрее,
> чуть ли не в 1.5-2 раза.Ну как бы в итоге все состоит из времени чтения + времени распаковки, и оптимальность сочетаний не константа и варьируется в зависимости от кучи факторов. В целом LZO относится к примерно тому же классу алгоритмов (скоростные "простые LZ") и профит от +1 алго по мнению девов btrfs в их кейсе умеренный. А вот например пожмешь /boot LZ4 а загрузчик и скажет "unknown compression", +1 алго в ФС не так уж безобидно.
> Я в основном тут смотрю цифры http://quixdb.github.io/squash-benchmark,
На самом деле это очень многофакторное и зависит от ряда соотношений (например мощь CPU и скорость RAM vs IO) и по факту лучше бенчить именно у себя на именно интересных кейсах. А чужие тесты в лучшем случае позволят ожидаемые соотношения прикинуть. Если понимать на что смотреть.
> странно правда, что там zstd только с 1 уровнем, но зато наглядно.
Ну как бы на более высоких уровнях жать будет медленнее. Распаковка примерно так же останется. Зависимость уровень vs скорость распаковки бывает, но слабая.
> В частности на графиках Ratio / Decompression видно, что lzo и lz4 вообще
> в разных областях располагаются, а zstd по скорости разжатия рядом с lzo,
> вот только он еще и жмет.
ИМХО LZO в целом поплотнее LZ4, а в ФС с требованием на рандомный seek и потому лимитом на размер блока zstd негде на полную разогнаться. И таки LZO побыстрее zstd во многих случаях и инициализация дешевле: поток LZ4 и LZO можно распаковывать с места в карьер, zstd и zlib в этом более навернуты и надо состояние entropy coder еще инитить.
> Я правда из датасетов там только enwiki и mozilla глядел, может для
> обычного десктопа оно и нерелевантно,
Учитывая что у ФС требование на рандомный доступ и потому лимит на размер блока - соотношения несколько изменятся. Сетап распаковки роялить больше будет.
> с /home lz4 с высоким уровнем, но подумал, что и zstd:1
> пойдет, а lzo - точно мимо.
Lzo имхо будет быстрее хоть какого zstd в тех случаях (на распаковку). У него фора есть, это "простой LZ" с довольно тривиальным потоком, как и LZ4, можно с места в карьер его распаковывать, даже без аллокаций памяти не говоря про инит кодера энтропии. А zstd куда навернутее, и такая развлекуха на каждый блок отольется по идее...
>> Совсем онлайн нету - и большой вопрос хотите ли вы именно это, именно так.
> Вроде на бумаге задача решаемая, пусть и с небольшим количеством приседаний.
Да и на практике решаемая, только это как компрессия с супер-большим словарем и потому оперативы немеряно жрет и CPU грузит весьма прилично. И хотите ли вы это все вот именно в момент записи - очень отдельный вопрос. Офлайн дедупы позволяют выбрать момент когда ресурсы тратить более контролируемо, отложенно. А штуки типа bees могут и околореалтаймно пахать, сканируя дельту относительно прошлого забега и дедупая только это. Но и так можно себе "windows vista" организовать, когда оно все время что-то делает и грузит систему.
> Если git clone делать в tmpfs или ramfs достаточного размера, тут уже
> ФС сможет оценить все, что будет писать на диск,
Проблема в том что для более-менее быстрого поиска дупов в RAM надо держать немеряную хештаблицу всех кандидатов, иначе скорость операции будет совсем печальной. Требует дофига рам, пропорционально объему стоража. Офлайн дедупалки могут пытаться какой-то компромисс с хранением индекса кандидатов в базе, так медленнее но снижает аппетиты к RAM. Которые могут начать измеряться десятками гигов на большом стораже.
> и решить как это лучше всего разместить, в т.ч. и с онлайн дедупликацией.
Проблема в том что процесс принятия решения чем-то напоминает сжатие в LZ (поиск совпадения хоть и с рядом ограничений) - ни разу не халявен по ресурсам.
> Выигрыш может будет и сомнительный, но если есть на это ресурсы
> - почему бы так не делать?
Ну вот поэтому ZFS с онлайн дедупом только на файлопомойках с кучей ресурса и юзают, там все равно CPU и RAM может быть некуда деть. А если это не выделенная файлопомойка то на проц и раму и другие претенденты есть.
> Это я так понял демон, который всю ФС смотрит, и опять же это оффлайн.
Это примерно на границе миров. Поскольку именно демон, и может процессить именно дельту, мониторя изменения, это начинает напоминать онлайн. А совсем оффлайн - это именно прога, не демон, пинаемая мануально по усмотрению юзера. Например jdupes или duperemove. Они ресурсы сами по себе не жрут совсем.
> А хотелось бы сразу скинуть на диск дедупнутую директорию.
В конечном итоге что так будет эн референсов на 1 экстент из метаданных что сяк. Отличия будут только на интервале пока дуп не отпроцессили. В ZFS это настолько ресурсоемко вышло что пользуется этим довольно мало кто в именно таком виде. Это вот реально для энтерпрайзных файлопомоек выделенных под задачу, на жирной машине.
> Да и обычно пользователю виднее, где могут быть потенциальные дубликаты, и
> проще "дедупликатор" ручками натравлять, чем мониторить диск 24/7.
Ну я как-то так и предпочитаю, чтобы вместо виндоус висты концентрированный жор ресурсов когда мне точно пофиг, скажем пока я сплю. Вон парочка примеров этсамого.
>> лучше всего попробовать самому и что понравится и пойдет под требования то и оставить
> Да на самом деле все ФС нормально работают и не требуют к
> себе повышенного внимания, особенно при обычной десктопной нагрузке. Вопрос скорее в
> том, что из ФС можно выжать и какой ценой.
Ну я вот из btrfs выжал нехилое улучшение надежности моих систем за счет парирования единичных бэдов, вплоть до того что на сыпучей флехе можно стало таскать файло. EXT* там за месяц в хлам разваливается, а btrfs живет уже пару лет с схемой DUP - чтобы выбило обе копии блока в разных физических смещениях я должен нехилый такой джекпот у теорвера сорвать. С законами природы не стоит спорить, гораздо лучше ими пользоваться себе во благо :). Или снапшоты. Почти как виртуалка. Не понравился результат апдейтов операционки? Снес полхомяка? Автор лох и сделал "rm /usr /bin/..." как в bumblebee? Ну ок, я откачусь на снапшот в котором все было ЗБС. Ведь сделать его моментально, второй раз хранится только "дельта", а в результате управление почти как в виртуалках. Удобно. Но при этом лучше понимать как работает гипердрайв этого крейсра, в частности cow vs снапшоты vs "хранение дельты". Иначе будут вопросы куда место делось. На виртуалках все то же самое.
