The OpenNET Project / Index page

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



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

Оглавление

В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering), opennews (??), 26-Май-20, (0) [смотреть все]

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


139. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 27-Май-20, 14:03 
> На данном же этапе ответственность за очистку возлагается на пользователя. Сброс данных с прокси-диска в основное хранилище производится простым вызовом утилиты...

Офигеть технологии, всё как всегда - через задницу. Если учесть, что под быстый диск будут выделять твёрдотельные накопители, то неплохо было бы все данные кодировать избыточно на несколько разных быстрых дисков и сбрасывать на медленные как можно быстрее. В предлагаемой архитектуре вся ФС может сдохнуть от частичной деградации быстрого диска с SSD.

Т.е. должен быть не просто сборос по крону, а специальный следящий за нагрузкой менеджер с приоритетами для метаданных.

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

158. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от Аноним (158), 27-Май-20, 16:37 
> Офигеть технологии, всё как всегда - через задницу.

Не, ну блин, это все же честно обозначено как preview технологии. И предъявлять при этом что-то довольно странно.

> данные кодировать избыточно на несколько разных быстрых дисков и сбрасывать на
> медленные как можно быстрее.

Один маленький нюанс: минимальная конфига получится стоимостью как самолет.

> В предлагаемой архитектуре вся ФС может сдохнуть
> от частичной деградации быстрого диска с SSD.

А вот как эта штука с деградацией разбирается я не совсем понял. В теории вроде может записывать более 1 копии или RAID-like кодирование. На практике это ускорит кончину кэш-диска.

> Т.е. должен быть не просто сборос по крону, а специальный следящий за
> нагрузкой менеджер с приоритетами для метаданных.

Походу unimplemented пока.

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

178. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 28-Май-20, 03:45 
> Не, ну блин, это все же честно обозначено как preview технологии. И предъявлять при этом что-то довольно странно.

У этой технологии вроде как обозначен план развития и сделать хорошо в него не входит. Типа реализуем идею, которой 100 лет в обед, и посмотрим что делать дальше - так не работает. Надёжность технологии из-за SSD нужно продумывать сразу.

> Один маленький нюанс: минимальная конфига получится стоимостью как самолет.

Это всего лишь 2-3 SSD/NVMe, доступно многим любителям.

> А вот как эта штука с деградацией разбирается я не совсем понял. В теории вроде может записывать более 1 копии или RAID-like кодирование.

И с поблочными контрольными суммами (на каждые N KiB данных), просто RAID или копии будет мало.

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

162. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от Аноним (39), 27-Май-20, 18:09 
Т.е. должен быть не просто сборос по крону, а специальный следящий за нагрузкой менеджер с приоритетами для метаданных.

Сказали же: менеджер будет после достижения бета-стабильности. Было из-за чего визг поднимать. Просто так легче отлаживать.

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

179. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 28-Май-20, 03:48 
Может быть, но есть подозрение что это будет чуточку продвинутый запуск предлагаемой команды по крону, а не полноценный планировшик перекачки. В тексте указано, что `быстрый` диск для ФС выглядит как обычный, а для планировщика нужно ещё прицеплять некоторвые метаданные или даже иначе использовать дисковое пр-во.
Ответить | Правка | Наверх | Cообщить модератору

195. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от Аноним (153), 28-Май-20, 12:34 
> не полноценный планировшик перекачки

У тебя каша в голове. Зачем для очистки что-то планировать? На таргете создали копию, после этого удалили объект на исходном диске.

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

197. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от all_glory_to_the_hypnotoad (ok), 28-Май-20, 14:22 
Конечный носитель может быть занят другим IO и если делать без планирования, то произойдёт размен отзывчивости ФС на быстрые burst write-ы. Для ФC честная отзывчивость (задержки) намного важнее быстрой записи. Т.е. где нужна быстрая запись приложения и так в состоянии нагородить свой лог.
Ответить | Правка | Наверх | Cообщить модератору

198. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от Аноним (153), 28-Май-20, 15:36 
> Конечный носитель может быть занят другим IO и если делать без планирования, то произойдёт размен отзывчивости ФС на быстрые burst write-ы. Для ФC честная отзывчивость (задержки) намного важнее быстрой записи. Т.е. где нужна быстрая запись приложения и так в состоянии нагородить свой лог.

Тебе по ходу лечиться нужно.

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

230. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от Аноним (230), 29-Май-20, 18:30 
> Конечный носитель может быть занят другим IO

В той стратегии, что тут анонсирована, приложения напрямик не него не пишут. Только читают.

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

239. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +1 +/
Сообщение от Аноним (-), 30-Май-20, 10:21 
> В той стратегии, что тут анонсирована, приложения напрямик не него не пишут.
> Только читают.

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

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

231. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от Аноним (231), 29-Май-20, 19:25 
Дело говорит. Только зачем мета-данные для планирования? Для этого нужна другая системная информация. С этой точки зрения диски равноправны.
Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

228. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от пох. (?), 29-Май-20, 16:22 
гы/гы - угадай, на что напоролась ms, сделав аналогичную хрень в виде mirror+ec ;-)

У них все честно, никакого ручного переписывания.

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

254. "В Reiser5 анонсирована поддержка Burst Buffers (Data Tiering..."  +/
Сообщение от Crazy Alex (ok), 04-Июн-20, 11:04 
Зачем такие извращения? Хочется дублирования - собери RAID и используй полученное устройство. А так - ну выдаст ошибку кэширующий диск - записать на основной.
Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

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

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




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

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