The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ветку ядра Linux-next добавлена реализация ФС Bcachefs, opennews (??), 20-Сен-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


36. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +2 +/
Сообщение от Аноним (36), 20-Сен-23, 12:08 
> nvme модулях работающих уже почти на скорости оперативки

Разница в пропускной способности на порядок, в лучшем случае (это если PCIe 5.0 и средний DDR5 сравнивать; если более дешманский PCIe 3.0 или 4.0, то всё еще печальнее). Разница в задержке на несколько порядков.

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

Ответить | Правка | Наверх | Cообщить модератору

65. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +1 +/
Сообщение от Минона (ok), 20-Сен-23, 14:26 
Во сколько раз сжимаются документы, раз в 10?
Ну будет у тебя отчёт открываться за 10 мс вместо 100, что ты выиграешь от разницы в 90 мс?
Ответить | Правка | Наверх | Cообщить модератору

75. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +1 +/
Сообщение от 1 (??), 20-Сен-23, 16:20 
Увеличение ЧСВ на порядок.
Ответить | Правка | Наверх | Cообщить модератору

76. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Аноним (36), 20-Сен-23, 16:22 
В первую очередь я выиграю место на диске, и уже одного этого мне будет достаточно. Во-вторую, я, возможно, выиграю в скорости загрузки и запуска приложений, если сожму директории с бинарниками, к примеру. Но тут выиграю или нет - зависит уже от скорости накопителя и CPU.
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

118. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от User (??), 20-Сен-23, 23:57 
Эм, смотря какие. Если docx - то не восколько, они уже пожаты. А если кто-то чего-то в любимом vi наплейнтекстил - то таки да, есть разница.
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

119. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +1 +/
Сообщение от Аноним (-), 20-Сен-23, 23:57 
> Во сколько раз сжимаются документы, раз в 10?
> Ну будет у тебя отчёт открываться за 10 мс вместо 100, что
> ты выиграешь от разницы в 90 мс?

Да вот видите ли - он выиграть может...
1) Доступное свободное место. А поди плохо если гигабайт подешевеет в пару раз?!
2) Износ накопителя. Сильно продвинутые и сами что-то могут попытаться изобразить - но это как минимум не транслируется в выигрыш по емкости, т.е. вон то все равно лучше.
3) Документы и вообще файлы - разные бывают. Где 10 мс а где и 10 с.
4) А если это сервак, то через всего то 1000 запросов 10 мс станут теми же 10 с.

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

133. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +1 +/
Сообщение от fumanchez (ok), 21-Сен-23, 01:40 
У меня хомяк похудел почти на треть с zstd при самой легкой степени сжатия, а там, к примеру, лежал флатпаковский .var (я с флагом --user все ставлю). А сервер в теории можно более равномерно загрузить, если он до этого не упирался в процессор.
Ответить | Правка | Наверх | Cообщить модератору

136. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +1 +/
Сообщение от Аноним (-), 21-Сен-23, 01:55 
> У меня хомяк похудел почти на треть с zstd при самой легкой
> степени сжатия,

А у меня система (и ее снапшоты!) раза в 2 с гаком полегчали на SSDшнике. Поди плохо то, если это еще и не в ущерб скорости, а то и с бонусом к ней. Я типа жаловатсья должен что мне гигов досыпали, а то и скорости? :)

> а там, к примеру, лежал флатпаковский .var (я с флагом --user все ставлю).

Я вообще не ставлю никакие флатпаки, ибо нафиг винды. Но на нормальной файлухе это кроме сжатия наверное еще и дедупнется неплохо.

> А сервер в теории можно более равномерно загрузить, если он до этого не упирался в процессор.

Ну как бы если IO еще и ускорится - то это всяко лучше. А если и нет - меньше займется места, меньше протирания SSD. Тоже неплохо.

Ответить | Правка | Наверх | Cообщить модератору

142. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от пох. (?), 21-Сен-23, 07:41 
> А у меня система (и ее снапшоты!) раза в 2 с гаком полегчали на SSDшнике. Поди плохо

просто пофигу. Никому в 2k23 неинтересно занимает ли твоя "система" вместе с ненужно-снапшотами которы ты никогда не будешь использовать, 12 гигабайт или восемь.  Вообще. Совсем.

Ответить | Правка | Наверх | Cообщить модератору

205. Скрыто модератором  –2 +/
Сообщение от Аноним (-), 21-Сен-23, 19:11 
Ответить | Правка | Наверх | Cообщить модератору

274. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от InuYasha (??), 24-Сен-23, 10:18 
Я до слёз от мысли как ты будешь файлы каким-нибудь O&O recovery по заголовкам искать. И не найдёшь. :D
Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

275. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от fumanchez (ok), 24-Сен-23, 10:54 
Был бы умный - знал бы, что жмется не все подряд.
Ответить | Правка | Наверх | Cообщить модератору

278. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от InuYasha (??), 24-Сен-23, 21:23 
И что же? Как, интересно, фс узнает, что у BMP-файла есть заголовки, а внутри что-то пожать можно? Ну, ерунда какая-то.
Ответить | Правка | Наверх | Cообщить модератору

280. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от fumanchez (ok), 25-Сен-23, 00:08 
Если тебе лень открывать документацию, то кратко: btrfs пытается сжать первые 128 КБ файла, чтобы прикинуть, стоит ли его жать, если конечно не проставлено принудительное сжатие. И хорошо жмется как правило то, что восстанавливать нет смысла - логи, бинарники, кеш и т.п..
Ответить | Правка | Наверх | Cообщить модератору

294. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от InuYasha (??), 27-Сен-23, 11:05 
Ну, это уже прямое нарушение OSI. ФС вообще сжатием заниматься не должна. Решение о сжатии должен софт принимать или юзер.
Ответить | Правка | Наверх | Cообщить модератору

295. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от fumanchez (ok), 27-Сен-23, 12:26 
ФС может хранить данные вообще как угодно, и решение таки принимает юзер - сжатие можно как не включать вовсе, так и отключить на отдельном subvolume. Если нравятся костыли по типу zcat и zgrep, то никто вас не отговаривает от такой ручной работы, но это лишняя сущность. Захотел ты по man'ам поискать что-то - grep с флагом -R уже не сделаешь, а в zgrep флага -R нет. И может я не хотел бы, чтобы man'ы были пожаты в .gz, или хотел бы, но чтобы в .zst.
Ответить | Правка | Наверх | Cообщить модератору

141. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +1 +/
Сообщение от пох. (?), 21-Сен-23, 07:26 
> Да вот видите ли - он выиграть может...
> 1) Доступное свободное место. А поди плохо если гигабайт подешевеет в пару

сколько его?

> раз?!

вообще похрен всем. Неплохо если терабайт подешевеет - но откуда у него СТОЛЬКО сжимаемых данных чтоб освободить терабайты.
> 2) Износ накопителя. Сильно продвинутые и сами что-то могут попытаться изобразить -

ему похрен вот вообще. Гугль целое исследование запилил (правда, двадцать лет назад).

> 3) Документы и вообще файлы - разные бывают. Где 10 мс а
> где и 10 с.

у меня для тебя опять облом - пока ты в криокамере мерз, ТАКИЕ документы перестали сжиматься, они уже.

> 4) А если это сервак, то через всего то 1000 запросов 10
> мс станут теми же 10 с.

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


Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

207. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Аноним (-), 21-Сен-23, 19:21 
>> Да вот видите ли - он выиграть может...
>> 1) Доступное свободное место. А поди плохо если гигабайт подешевеет в пару
> сколько его?

А где как. На системных SSDшниках места не так уж и дохрена, оно денег сотит, а там на него и еще претендентов немеряно. У меня /builds весит более 300 гиг. И то что он сжался раза в 2.5 было очень кстати так то.

> вообще похрен всем. Неплохо если терабайт подешевеет - но откуда у него
> СТОЛЬКО сжимаемых данных чтоб освободить терабайты.

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

>> 2) Износ накопителя. Сильно продвинутые и сами что-то могут попытаться изобразить -
> ему похрен вот вообще. Гугль целое исследование запилил (правда, двадцать лет назад).

Ну я больше верю статистике своих девайсов чем каким-то гугелям. И просто здравому смыслу.

> у меня для тебя опять облом - пока ты в криокамере мерз,
> ТАКИЕ документы перестали сжиматься, они уже.

Ну, э, попробуй поработать с УЖЕ СЖАТЫМ osm planet xml - под 300 гигз штука. Там правда есть и более разумные форматы, в том числе и уже-сжатые. Но planet xml больше софта жрет и вот там декомпресс от и до почти 300 гигз архивером - видите ли очень напрягает. А прозрачно и фс, может даже сделать лучше чем было. Seek в произвольное место же остается.

> А сервант твой потеряет гораздо больше времени на обработку запроса а не
> собственно отдачу файла.

Если сервант на 1000 запросов профакивает 10 секунд - что он там делал? Пыхтонрас чтоли запускал?

> Особенно если он пришел к нам из тех же годов что чудо-диски по терабайту.

И тем не менее, не вижу проблем юзать технологию если она улучшает состояние дел. А уж какой LZ4 даже и на энтерпрайзном SSD может не спасовать по скорости распаковки.

Ответить | Правка | Наверх | Cообщить модератору

211. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от пох. (?), 21-Сен-23, 20:23 
> А где как. На системных SSDшниках места не так уж и дохрена, оно денег сотит, а там на него и еще
> претендентов немеряно. У меня /builds весит более 300 гиг.

страдания долбанавтов держащих какой-то ненужный мусор в системном разделе вместо системы - очень конечно ценны для мироздания (нет)

>> ему похрен вот вообще. Гугль целое исследование запилил (правда, двадцать лет назад).
> Ну я больше верю статистике своих девайсов чем каким-то гугелям. И просто здравому смыслу.

ну да, ну да - типа тех что выше. Куда там гуглю с его миллионами серверков. (вот у него - статистика, а не высосанные из пальца на основании трех экземпляров прогнозы)

> Ну, э, попробуй поработать с УЖЕ СЖАТЫМ osm planet xml - под 300 гигз штука.

сочувствую.

> Seek в произвольное место же остается.

естественно, нет. Имитируется с изрядными потерями.


> И тем не менее, не вижу проблем юзать технологию если она улучшает состояние дел.

пока она не превращает твои данные в невосстановимую кашу. Что с модными технологиями увы сплошь и рядом.

Ответить | Правка | Наверх | Cообщить модератору

220. "В ветку ядра Linux-next добавлена реализация ФС Bcachefs"  +/
Сообщение от Аноним (220), 21-Сен-23, 21:35 
> страдания долбанавтов держащих какой-то ненужный мусор в системном разделе вместо системы
> - очень конечно ценны для мироздания (нет)

Я уже понял что твой потолок использования компьютеров - это хомячить. А софт видимо как булки. на деревьях растет. И остальное тоже.

> ну да, ну да - типа тех что выше. Куда там гуглю
> с его миллионами серверков. (вот у него - статистика, а не
> высосанные из пальца на основании трех экземпляров прогнозы)

А кто сказал что ворклоады гугля похожи на мои? Поэтому ориентироваться на локальные показатели в конкретике мне как-то больше доверия внушает.

>> Ну, э, попробуй поработать с УЖЕ СЖАТЫМ osm planet xml - под 300 гигз штука.
> сочувствую.

Да чего мне сочувствовать? Я в результате могу себе up-to-date карты "региона интереса" с нужными объектами, вот, скрафтить, по вкусу, за обозримое время. Из глобальных общепланетарных данных OSM. И далее навигировать по этому - в полном офлайне, не спрашивая "благодетелей" типа гугла и проч, c пофигом на то есть ли в локации интернет вообще. Это позволяет мне быть в аспекте "навигация" сильно выше средне-хомячьего. Имел возможность сравнить.

>> Seek в произвольное место же остается.
> естественно, нет. Имитируется с изрядными потерями.

Да ну там максимум кил 128 чтоли, и это быстро распаковывается а seek в XML не так уж часто нужен. На выбор жатые protobuf - они компактней в 10 раз но видите ли там random seek нету и скорость процессинга ничуть не лучше, а есть o5m - уже более потребное по структуре, но с ним мало софта работать умеет, вот и выбирай? что называется, как эту "бигдату" окучивать. Как одна из опций распакованая но сжатая ФС чушка XML - не такой уж плохой вариант оказался.

>> И тем не менее, не вижу проблем юзать технологию если она улучшает состояние дел.
> пока она не превращает твои данные в невосстановимую кашу. Что с модными
> технологиями увы сплошь и рядом.

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

А вот как ты из тех железок LVM и проч эрзац варпдрайва пытался собрать для меня вообще загадка, тем более что работает это все еще сыкотнее - ну я и не понял почему оно круто и безопасно. Если для тебя это лучше пашет - ну и лажушки. А я лучше вон то погоняю. Каждый человек имеет выбор - а потом выбор человека.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру