The OpenNET Project / Index page

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



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

Оглавление

Опубликована платформа SEF для программно управляемых Flash-накопителей, opennews (??), 12-Дек-23, (0) [смотреть все]

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


49. "Опубликована платформа SEF для программно управляемых Flash-..."  +1 +/
Сообщение от Бывалый смузихлёб (?), 13-Дек-23, 12:50 
> Зато (голой) скорости прибавится вполне вероятно

Учитывая что для возни с банками твердотельника выделен контроллер( отдельный многоядерный проц со специфическими аппаратными блоками ) и отдельная ОЗУ, то перенос всего этого на сторону компа и ОС относительно "голой" прошивки едва ли повысит скорость работы при прочих равных( включая нагрузку на ЦП )

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

64. "Опубликована платформа SEF для программно управляемых Flash-..."  +1 +/
Сообщение от Аноним (-), 13-Дек-23, 17:00 
> и ОС относительно "голой" прошивки едва ли повысит скорость работы при
> прочих равных( включая нагрузку на ЦП )

Вот ща бы при многоядерниках даже в телефоне проц только и экономить. Если даже пара ядер целиком уйдет под обслугу этого - кто вообще это заметит? Заодно и алгоритмы могут быть попродвинутее, ядра в мелком чипе в пластиковом корпусе в TDP жестко ограничены, тем более что рядом флеш который нагрев не любит (как следует нагрев флеш его вообще можно стереть).

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

69. "Опубликована платформа SEF для программно управляемых Flash-..."  –1 +/
Сообщение от Бывалый смузихлёб (?), 13-Дек-23, 18:27 
> Вот ща бы при многоядерниках даже в телефоне проц только и экономить.
> Если даже пара ядер целиком уйдет под обслугу этого - кто
> вообще это заметит?

Если на обслуживание 1 накопителя уйдёт 2 ядра, то на 2 накопителя уйдёт уже 4 ядра
Без учёта большой протяжённости линий и хз какого поведения в случае нарушения контакта

> Заодно и алгоритмы могут быть попродвинутее, ядра в
> мелком чипе в пластиковом корпусе в TDP жестко ограничены, тем более
> что рядом флеш который нагрев не любит (как следует нагрев флеш
> его вообще можно стереть).

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

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

77. "Опубликована платформа SEF для программно управляемых Flash-..."  +1 +/
Сообщение от Аноним (-), 13-Дек-23, 21:39 
> Если на обслуживание 1 накопителя уйдёт 2 ядра, то на 2 накопителя
> уйдёт уже 4 ядра

Ну так там и проц поди будет минимум ядер на 16+. Вон там амд с интелем соревнуются кто больше ядер впихнет. И даже ARM могут скажем 4 big + 4 LITTLE ядер втолкать, получив 8-ядерный мобильник или планшет, а серверные типа Ampere и того больше.

> Без учёта большой протяжённости линий и хз какого поведения в случае нарушения
> контакта

Шины либо укладываются в спеки, либо нет. А число контактов примерно одинаковое остается. Более того, глючные проприетарные фирмвари всех задолбали. Достаточно посмотреть что этот крап откаблучивает. В некоторых EVO вообще TRIM запретили, ибо отъехашая мозгами фирмвара норовит TRIMнуть по ошибке свои внутренности и внезапно и резко скопытиться на радость юзера. Линух в курсе и ряд ревизий ЭТОГО КРАПА блеклистит. Но реально никогда не знаешь что и почему оно откаблучит. А также насколько правдива статистика, как оно РЕАЛЬНО себя ощущает и проч. Не, простите, абстрактные попугаи показали что это - совершенно неинформативный юнит, по которому сложно делать выводы.

> От тех ядер, по сути, требуется принять пачку данных, отослать в кеш
> и раскидывать по банкам по мере неспешной отработки записи флешем, отслеживая
> состояние и статусы. Вдобавок, у них лишних прослоек по минимуму, есть
> возможность впилить ОСРВ

Проблема в том что это все выросло в довольно большое и глючное, весьма малопредсказуемое, субоптимальное и переусложненное комбо. Где фирмварь пытается косплеить механический диск из того что им не является, путем ацких извратов. Операционка пытается отменить этот подарок через костыли типа TRIM, группировки операций и проч.

> Перекладывание этого специализированного мартышкиного труда на проц общего назначения,
> ещё и с кучей прослоек вплоть до полноценной ОС которая даже
> не реального времени - как-то очень сомнительно выглядит в плане производительности
> и стабильности ОС зависла - диску хана. Прямо анекдот

Слетевшие трансляторы намекают что это так то и фирмвари накопителей - умеют. И чем линух хуже как транслятор? И да, линух серьезно метит в RTOS так то. Он до кучи уже это наполовину. Там остались еще кой какие костыли для консолей чтобы они были async/threaded и не могли ничего якорить (реалтайм не ждет!) но остальное почти все утрамбовали.

...а так по приколу у меня есть и пара железок с RAW NAND и UBI+UBIFS поверх них. Работает себе, ничего не слетат. Правда это комбо ОК только для SLC, для MLC с его заскоками оно недопиленое.

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

91. "Опубликована платформа SEF для программно управляемых Flash-..."  +/
Сообщение от Kuromi (ok), 14-Дек-23, 17:00 
>  В некоторых EVO вообще TRIM запретили, ибо
> отъехашая мозгами фирмвара норовит TRIMнуть по ошибке свои внутренности и внезапно
> и резко скопытиться на радость юзера. Линух в курсе и ряд
> ревизий ЭТОГО КРАПА блеклистит. Но реально никогда не знаешь что и
> почему оно откаблучит. А также насколько правдива статистика, как оно РЕАЛЬНО
> себя ощущает и проч. Не, простите, абстрактные попугаи показали что это
> - совершенно неинформативный юнит, по которому сложно делать выводы.

Там запретили асинхронный TRIM (т.е. команды на TRIM идут вместе обычными на чтение\запись данных) который в Линуксе задействуется когда включен continuous TRIM. Вот это глючило, да, оказалось что многие Самсунги хоть и говорят что могут одновременно тримить и работать как обычно но на деле очень не любят, у других производителей такого не было замечено.

Прикол в том что continuous TRIM вообще нигде кроме Линукс не поддерживается, да и под  Линуксом он не рекомендуется. Везде явный вызов с большим диапазоном и ожиданием пока накопитель не почистится.

Условный f2fs или btrfs делает это иначе, собирает данные-кондидаты на TRIM в фоне, а потом во время простоя их чистит. По сути мало чем отличается от continuous, только без глюков.

А вообще с TRIM всегда все сложно. В одним устройствах он может вызывать полный стоп на какой-то промежуток времени, устройство почти перестает отвечать (зато быстро), в других снижается производительность на какое-то время, пока устройство в фоне чистится, вот так Самсунги себя обычно вели, может потому и проблемы. Главная неприятность тут что Самсунг сначала вообще не признавали проблему со своими накопителями. Обещали исправить в прошивке, а исправили ли - вопрос. Последние годы их вообще ругают, что их прошивки глючат, так сказать "победитель расслабился".

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

119. Скрыто модератором  +/
Сообщение от Аноним (-), 17-Дек-23, 22:45 
Ответить | Правка | Наверх | Cообщить модератору

122. Скрыто модератором  +/
Сообщение от Kuromi (ok), 17-Дек-23, 23:05 
Ответить | Правка | Наверх | Cообщить модератору

124. Скрыто модератором  +/
Сообщение от Аноним (-), 18-Дек-23, 00:28 
Ответить | Правка | Наверх | Cообщить модератору

125. Скрыто модератором  +/
Сообщение от Kuromi (ok), 18-Дек-23, 00:36 
Ответить | Правка | Наверх | Cообщить модератору

126. Скрыто модератором  +/
Сообщение от Аноним (96), 18-Дек-23, 04:12 
Ответить | Правка | Наверх | Cообщить модератору

90. "Опубликована платформа SEF для программно управляемых Flash-..."  +/
Сообщение от Kuromi (ok), 14-Дек-23, 16:28 
>> Зато (голой) скорости прибавится вполне вероятно
> Учитывая что для возни с банками твердотельника выделен контроллер( отдельный многоядерный
> проц со специфическими аппаратными блоками ) и отдельная ОЗУ, то перенос
> всего этого на сторону компа и ОС относительно "голой" прошивки едва
> ли повысит скорость работы при прочих равных( включая нагрузку на ЦП
> )

А вы уверены что они выкинут вообще все, включая процы контроллера? Прошлый раз когда я читал про вот такие подвижку в сторону осовременивания флеш-памяти там четко именно таблица трансляции была означена источником всего зла. Мол вот уберем, разгрузим контроллер и будет летать. Часть функций можно оставить.
Отдельная ОЗУ в основном нужна для хранения этой самой таблицы и может чуть чуть самого кэша. Контроллер для совсем своих нужд часто использует встроенную свою ОЗУ, так например происходит на dram-less SATA SSD - там по HMB памяти не попросить.

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

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

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




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

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