The OpenNET Project / Index page

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



"Опубликована платформа SEF для программно управляемых Flash-накопителей"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Опубликована платформа SEF для программно управляемых Flash-..." +1 +/
Сообщение от Аноним (-), 13-Дек-23, 16:57 
>> Куча флех и ссдшек помирает из-за скоропостижной кончины контроллера.
> Контроллер там живее всех живых, если умирает контроллер - устройство вообще признаков
> жизни не подаёт! Такое ну оооочень редко встречается.

Уж как минимум слет трансляции - весьма распостраненное явление.

> А флеш-память на самом деле тоже не совсем умирает. В любой флешке/SSD/SD-карте
> часть ёмкости зарезервирована для ремапов. Когда слишком много bad-block'ов появляется
> - заканчиается место для ремапов и контроллер переводит диск в режим
> read-only. Типа "ресурс исчерпан".

Это если повезет. Если не повезет - начинает грузить труху (uncorrectable после FEC уж как вышло?) - забыв IO error вообще зарепортить. И этим периодически грешит почти все флешовое, от SD карт до энтерпрайзных SSD.

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

Вообще - и они IIRC таки перешиваются, но это все vendor cmd которые вам, разумеется, никто не расскажет. Для некоторых однако даже программы есть. В каких-то из SD некто даже делал бэкдоры на уровне фирмвари их мк - отдавал левый сектор вместо записаного. Так что карта может в принципе отгрузить нечто левое не хуже флешки или SSD, если захочет.

А так там просто фирмварь обычно примитивная, резерв минимальный, конструкция стремная -  сэкономлено на всем.

> Тут такой момент. Если "размазывание" ресурса записи работает правильно, то все блоки
> на диске начнут умирать в одно время... Но на практике так бывает только у SSD!

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

> На флешке достаточно FAT-таблицу разместить не в том месте (не там, где это
> ожидал производитель) и сразу появляется много bad-блоков.

Там еще проблема в том что фабричный partition и FAT - выровнены на Erase Block и страницы, одновременно.

Если не угадать с выравниванием на страницы, скорости записи капец и протирание в пару раз сильнее - потому что теперь запись 1 сектора будет не 1 страница, а чтение-модификация-перезапись двух, на границе сектора.

А с erase block - опять же срывает wear leveling на уровне крупных блоков удваивая запись, а заодно - при слете питания можно лишиться таблицы разделов. Когда контроллер будет RMW на копии фата гонять, питание слетит, это записаться не успеет и... и кроме попорченой копии FAT (благо, их две и это не фатально) - вот вам пустая таблица разделов, флешка/карта/... резко и неприятно становится тыквой. Это лечится конечно - но угадывать куда разложить партишн все же мануальщина уже и обычный юзер так не умеет.

> Флешка будет живой, просто несколько мегабайт у неё укатаны
> и контроллер считает, что больше из диска ничего не выжать.

Вообще-то нормальный контроллер ремап на резервные блоки умеет, как и wear leveling. Даже у SD карт худо-бедно. При этом если wear leveling хоть немного работает, укатается по всей площади как раз.

> На самом деле можно ещё много чего выжать! Достаточно перешить флешку (желательно
> с большим размером резервной области для ремапов), ну там bad-блоки все
> найти не использовать их

В вендорских прогах есть реформат, с перепроверкой блоков и выбором сколько зарезервировать.

Аналогичные процедуры можно самому, на голом NAND, используя UBI и поверх него UBIFS. И там вон то соотношение выбирается совершенно штатно, по вкусу.

> (это будет низкоуровневое форматирование сразу после прошивки
> контроллера); естественно ёмкость такого накопителя будет поменьше, но прожить
> он может ещё долго...

Да как повезет на самом деле.

> У меня, например, Transcend старый 8Гб (MLC) живёт уже 12 лет, я
> его раза 4 перешивал, первый раз в 2017-м. В принципе, если
> бы можно было оставить под резерв около 30% ёмкости, то это
> была бы просто неубиваемая флешка... но ёмкостью 5-6Гб, вмести 7 с
> копейками ;)

Насчет неубиваемости спорный вопрос - данные то теряться будут. Хотя я на одну сыпучку btrfs с dup разложил, там флеха сыпется, контроллер отдает "как есть" без IO error, обычная файлуха там больше месяца - не выживает, сбои накапливаются и капец. А btrfs с 2 копиями блокоа на 1 девайс (схема "DUP") - чертыхается на CSUM ERROR, чинит, но "еж пищит, орет но живет". Вероятность что (редко) не читающиеся секторы попадут под сразу обе копиии - произведение вероятностей, и так теорвер намного интереснее. В результате ценой ополовинивания емкости сыпучка оказывается в общем то довольно юзабельная. Но конечно ценные данные на ней держать нафиг надо.

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

Оглавление
Опубликована платформа SEF для программно управляемых Flash-накопителей, opennews, 12-Дек-23, 23:41  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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