>> Да вот видите ли - он выиграть может...
>> 1) Доступное свободное место. А поди плохо если гигабайт подешевеет в пару
> сколько его?А где как. На системных SSDшниках места не так уж и дохрена, оно денег сотит, а там на него и еще претендентов немеряно. У меня /builds весит более 300 гиг. И то что он сжался раза в 2.5 было очень кстати так то.
> вообще похрен всем. Неплохо если терабайт подешевеет - но откуда у него
> СТОЛЬКО сжимаемых данных чтоб освободить терабайты.
Ну я вот например софт билдую чартерными рейсами, в том числе и довольно увесистый, мало ли. А иногда у меня достаточно забавные датасеты вот есть. Ну там например здоровенные вербозные трейсы всякой отладочной байды. Которые жмутся изумительно - а вот размер может быть довольно почтенный, ибо трекало что-то довольно быстрое, околореалтаймно.
>> 2) Износ накопителя. Сильно продвинутые и сами что-то могут попытаться изобразить -
> ему похрен вот вообще. Гугль целое исследование запилил (правда, двадцать лет назад).
Ну я больше верю статистике своих девайсов чем каким-то гугелям. И просто здравому смыслу.
> у меня для тебя опять облом - пока ты в криокамере мерз,
> ТАКИЕ документы перестали сжиматься, они уже.
Ну, э, попробуй поработать с УЖЕ СЖАТЫМ osm planet xml - под 300 гигз штука. Там правда есть и более разумные форматы, в том числе и уже-сжатые. Но planet xml больше софта жрет и вот там декомпресс от и до почти 300 гигз архивером - видите ли очень напрягает. А прозрачно и фс, может даже сделать лучше чем было. Seek в произвольное место же остается.
> А сервант твой потеряет гораздо больше времени на обработку запроса а не
> собственно отдачу файла.
Если сервант на 1000 запросов профакивает 10 секунд - что он там делал? Пыхтонрас чтоли запускал?
> Особенно если он пришел к нам из тех же годов что чудо-диски по терабайту.
И тем не менее, не вижу проблем юзать технологию если она улучшает состояние дел. А уж какой LZ4 даже и на энтерпрайзном SSD может не спасовать по скорости распаковки.
