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

"Опубликована платформа SEF для программно управляемых Flash-накопителей"	+/–
Сообщение от opennews (??), 12-Дек-23, 23:41
Организация Linux Foundation представила первый выпуск открытой платформы для программно управляемых Flash-накопителей SEF SDK (Software Enabled Flash), построенной на основе кода, переданного компанией KIOXIA (до переименования Toshiba Memory Corporation), в которой в 1980 году была изобретена Flash-память. Исходные тексты инструментария написаны на языке Си и распространяются под лицензией BSD... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60278
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Опубликована платформа SEF для программно управляемых Flash-..."	+4 +/–
Сообщение от Аноним (1), 12-Дек-23, 23:41
Ничего не понятно, но очень интересно.
Ответить | Правка | Наверх | Cообщить модератору

	3. "Опубликована платформа SEF для программно управляемых Flash-..."	+9 +/–
	Сообщение от Аноним (3), 13-Дек-23, 00:15
	Все прекрасно понятно: накопитель сознательно превращается в максимально тупое устройство, не пытающееся проявлять разум, проявлять который теперь будет хост, которым мы рулим.
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Опубликована платформа SEF для программно управляемых Flash-..."	+2 +/–
	Сообщение от Kuromi (ok), 13-Дек-23, 00:18
	Идея в том чтобы вытащить всю ту логику что сейчас делает контроллер, вроде выравнивания износа в драйвер на хосте. С одной стороны это хорошо, например позволит избавиться от слоев трансляции реальных адресов по которым лежать данные на флеше в "виртуальные", что выдает контроллер симулируя что-то HDD-подобное, например, позволит более четко понимать состояние флеш-памяти, степень износа. С другйо стороны потребуются новые файловые системы, и слегка оптимизированными вроде f2fs тут не отделаешься, потребуется что-то вроде JFFS2 чтобы разумно распоряжаться ресурсами NAND. Зато (голой) скорости прибавится вполне вероятно и наконец-то SSD перестанут умирать внезапно.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	12. "Опубликована платформа SEF для программно управляемых Flash-..."	+1 +/–
	Сообщение от Аноним (-), 13-Дек-23, 00:42
	Куча флех и ссдшек помирает из-за скоропостижной кончины контроллера. Отсюда вопрос, а где хранить метаданные для такой системы? (аналогичные тем, что были в контроллере) На другом хдд наверное будет слишком медленно, на ссдшке... тут мы получаем проблему Quis custodiet ipsos custodes ) Возможно, для такого можно брать какую-то крутую дорогую памть типа MRAM/ReRAM, но это не моя сфера, так что возможно я пишу чушь.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Kuromi (ok), 13-Дек-23, 02:33
	Хороший вопрос. Либо на хосте либо на самом устройстве либо отдельно выделенная зона на том же устройстве, в идеале аппаратно независимая. С другой стороны, а о каких метаданных особо будет идти речь? Слоя трансляции не будет, данные о износе?
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Анонимусс (?), 13-Дек-23, 13:57
	Да, под метадатой я имел в виду данные о износе, информацию о разделении на виртуальные накопители, их приоритетность и тд. Так же в статье упоминяется, что могут использоваться различные алгоритмы - этот код тоже нужно где-то хранить.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Tron is Whistling (?), 13-Дек-23, 09:49
	Метаданные внезапно хранятся всё в том же флеше.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	86. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Kuromi (ok), 14-Дек-23, 15:59
	> Метаданные внезапно хранятся всё в том же флеше. В обычных SSD - да, да и сама прошивка чаще всего - тоже. Поэтому слеты таблицы трансляции и прошивки - самая частая причина смерти.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (56), 13-Дек-23, 14:44
	>помирает из-за скоропостижной кончины контроллера. А тут не будет контроллера, значит помирать контроллер не может
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	87. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Kuromi (ok), 14-Дек-23, 16:03
	>>помирает из-за скоропостижной кончины контроллера. > А тут не будет контроллера, значит помирать контроллер не может Контроллер какой-то все равно будет, ты же не пишешь в ячейки напрямую, просто он станет проще и глупее. Уже не будут нужны наборная RAM чтобы хранить таблицу (а это, внезапно 1Мб на 1Гб NAND), не будет нужно хранить прошивку в устройстве, хитрые алгоритмы коррекции, правда все равно будет нужно распознавать уровни заряда ячейки, что тоже требует "ума".
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (61), 13-Дек-23, 16:30
	> Куча флех и ссдшек помирает из-за скоропостижной кончины контроллера. Контроллер там живее всех живых, если умирает контроллер - устройство вообще признаков жизни не подаёт! Такое ну оооочень редко встречается. А флеш-память на самом деле тоже не совсем умирает. В любой флешке/SSD/SD-карте часть ёмкости зарезервирована для ремапов. Когда слишком много bad-block'ов появляется - заканчиается место для ремапов и контроллер переводит диск в режим read-only. Типа "ресурс исчерпан". SD-карты, кстати, это часто делают по ошибке из-за плохо питания (а поскольку контроллеры там не перешиваются и, видимо, используется какая-то OTP-перемычка - это уже никак назад не отменить). Тут такой момент. Если "размазывание" ресурса записи работает правильно, то все блоки на диске начнут умирать в одно время... Но на практике так бывает только у SSD! На флешке достаточно FAT-таблицу разместить не в том месте (не там, где это ожидал производитель) и сразу появляется много bad-блоков. Флешка будет живой, просто несколько мегабайт у неё укатаны и контроллер считает, что больше из диска ничего не выжать. На самом деле можно ещё много чего выжать! Достаточно перешить флешку (желательно с большим размером резервной области для ремапов), ну там bad-блоки все найти не использовать их (это будет низкоуровневое форматирование сразу после прошивки контроллера); естественно ёмкость такого накопителя будет поменьше, но прожить он может ещё долго... У меня, например, Transcend старый 8Гб (MLC) живёт уже 12 лет, я его раза 4 перешивал, первый раз в 2017-м. В принципе, если бы можно было оставить под резерв около 30% ёмкости, то это была бы просто неубиваемая флешка... но ёмкостью 5-6Гб, вмести 7 с копейками ;)
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	63. Скрыто модератором	+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ообщить модератору

	71. Скрыто модератором	+/–
	Сообщение от Аноним (61), 13-Дек-23, 19:22
	> Если не угадать с выравниванием на страницы, скорости записи капец и протирание в пару раз сильнее - потому что теперь запись 1 сектора будет не 1 страница, а чтение-модификация-перезапись двух, на границе сектора. Для флешек/SD это очень важно, для первых SSD тоже была важно. Но думаю так - если флешка заявила сектор 512 байт, то самое главное в прошивке учтено: последовательная запись нескольких секторов приведёт к перезаписи одной страницы. Тогда ресурс снизится ну раза в 2 (вместо одного блока будет перезаписано 2; fat-таблица в любом случае с примерно одинаковой интесивностью перезапиывается, а размер кластера в FAT большой. ИМХО, для многих современных SSD-контроллеров ВСЕ (!!!) данные проходит через remap  (после записи часто переносится/"уплотняется", потом ещё стирание явно идёт и т.д.), поэтому выравнивание по границам секторов уже бессмысленно, данные никогда не попадут на диск как тебе хотелось ;) > Когда контроллер будет RMW на копии фата гонять, питание слетит, это записаться не успеет На флеш (raw flash) есть очень надёжный механизм коммитов. Всегда можно побитово перезаписать 1->0, 1->1 и даже 0->0. Нельзя только перезаписать 0->1, тут придётся сначала вычитать страницу, потом её стереть, и только потом на место единичек записать нужные данные ;) Это свойство как раз и используют при реализации ремапов и оно глючит ну ооочень редко. Если производитель в прошивке накосячил, или страничка для транзакций померла как раз во время ремапа. На практике, даже начинающие программисты для микроконтроллеров очень легко делают надёжный код, используя это свойство флеша. Глюканёт такой код только когда помрёт страница флеша. > В вендорских прогах есть реформат, с перепроверкой блоков и выбором сколько зарезервировать. Там иногда 1%, 3%, ну бывает 5% и 10% максимум (не у всех). А хотелось бы больше. При использовании TRIM (или при использовании FS с закольцовыванием как в f2fs/nil2fs) ресурс износа примерно выравнивается по всему диску. Конечно может отдельный сектор умереть и на такой случай ремап 3% - ну прям офигенно много. Но по факту страницы на флешках изношены неравномерно, т.к. на диске ФС FAT без TRIM и очень быстро укатываются конкретные "горячие" области диска (например, FAT-таблица). Может что-то там и не выравнено по границам erase-block, но это уже не так важно (ну в пару раз уменьшится ресурс, см выше). По факту получается - flash ещё не "посыпалась" (у остальных секторов ресурс-то ещё огого), а у контроллера ремапы кончились! Они все ушли на резервирование "горячих областей" диска, а оставшаяся часть имеет ещё ого-го какой ресурс. > Вообще-то нормальный контроллер ремап на резервные блоки умеет, как и wear leveling. Даже у SD карт худо-бедно. Да, ремап работает! Если бы он не работал - флешки бы умирали за неделю ;) примерно как умирают флешки из китая (там видимо пара секторов всего для ремапа). Но тут проблема - на флешках FAT и без TRIM :( Поэтому "выровнять" ресурс записи по всей флешке нереально! Сейчас уже есть SSD, у которых начало диска (первые пару гигабайт) имеют прям очень большой ресурс записи. А остальная часть - ну сколько там выдал TLC/QLC... Думаю, что у флешек подобный механизм используется очень давно как раз под FAT-таблицы. Но видимо не всегда помогает ;)
	Ответить | Правка | Наверх | Cообщить модератору

	75. Скрыто модератором	+/–
	Сообщение от Аноним (-), 13-Дек-23, 21:25
	> Для флешек/SD это очень важно, для первых SSD тоже была важно. Ну да. Лучше не проверять насколько фирмвара SSD с этим справится. > Но думаю так - если флешка заявила сектор 512 байт, то самое > главное в прошивке учтено: последовательная запись нескольких секторов приведёт к перезаписи > одной страницы. Тем не менее, если скажем 4K-блок ФС попал на пересечение страниц (в идеале тоже могут быть 4К, хотя у разных флех разное, это самый простой пример) - ради 1 блока придется ворочать 2 страницы. А в фабричном формате - одну. Откуда и фэйл с скоростью random write. > Тогда ресурс снизится ну раза в 2 (вместо одного > блока будет перезаписано 2; fat-таблица в любом случае с примерно одинаковой > интесивностью перезапиывается, а размер кластера в FAT большой. На самом деле что угодно может быть - очень зависит от логики фирмвари. Производителей и версий оной легион, и их поведение совпадать не обязано. > ИМХО, для многих современных SSD-контроллеров ВСЕ (!!!) данные проходит через remap В флеш вообще нельзя произвести запись без remap. У флеша есть "erase" и "program" - там вообще нет такого понятия как перезапись. При том erase - огромным блоком, у современных 4 мега и более может быть. А program - постранично, но после записи очистить можно только всем скопом - для eraseblock'а. Это связано с топологией кристалла, стирать сразу группой экономичнее по проводам и транзисторам, ячейка меньше площади занимает (по сравнению с произвольно адресуемым EEPROM где стирание и прогрммирование возможно для каждого байта отдельно). Поэтому совершенно любая штука вывешивающая якобы работу с якобы секторами делает нехилую трансляцию by design. А слет транслятора - довольно фатальный факап. > (после записи часто переносится/"уплотняется", потом ещё стирание явно идёт и т.д.), Любой флешовый девайс примерно так работает: у флеша eraseblocks немеряные, а страницы очистить можно только стиранием всего eraseblock. В продвинутых контроллерах несколько каналов и они любят интерливинг операций на эн каналов для скорости. Это дает старт понятию EraseGroup, когда операции ворочают для скорости сразу с несколькими чипами - параллельно на всех каналах. Erase довольно медленная операция, это разгоняет скорость в N раз. По той же причине trim важен - позволяет GC фирмвари почистить eraseblocks в фоне, не нарываясь на паршивую скорость операции ERASE при записи - оно сделано заранее. Так что для более продвинутых SSD может иметь некий смысл попытаться выравнять партишн и /boot раздел на вот это вот. Угадать разумеется сложно, но круглые юниты типа 256 мегов имеют шанс (физически это Eraseblock * channels). Это чтобы в случае внезапного слета питания по крайней мере без партишна не остаться. Ах да, снимать питание без информирования накопителя нельзя ни в SSD, ни в флехах, ни даже в SD картах. Потому что они вот могут гонять фоновые операции. И слет питания в этот момент может вызвать конкретный факап. Хорошие контроллеры обычно это переживают, но - логгят факап, накручивая счетчик. И если что, это повод послать в гарантийке, видимо. А более поганые девайсы могут от необдуманного сдерга транслятор потерять и вот это - знатный облом. > поэтому выравнивание по границам секторов уже бессмысленно, данные никогда не попадут > на диск как тебе хотелось ;) Вообще, таки есть шансы что даже так операции фирмвари упростятся до частных случаев. Но это как повезет. Что и является заметным минусом решения - никогда не знаешь что оно откаблучит. >> Когда контроллер будет RMW на копии фата гонять, питание слетит, это записаться не успеет > На флеш (raw flash) есть очень надёжный механизм коммитов. Там есть Erase и Program. Им самим по себе вообще все вон то неведомо. Остальное делается фирмварой и уровнем транстяции. > Всегда можно побитово перезаписать 1->0, 1->1 и даже 0->0. Не так! В совсем "классическом" виде: ERASE сбрасывает все биты (всех страниц) большого ERASEBLOCK в 1 (стертый флеш читается как 0xFF). PROGRAM позволяет сделать из 0xFF то что хочется, но только если это переход 1 -> 0 (0xFF можно превратить во что угодно). Обратно только стиранием всего ERASEBLOCK и всей оравы в несколько мегов. Гранулярность PROGRAM и возможность дозаписи страницы - варьируется. В NOR с интерфейсом шины можно даже отдельные байты или word'ы (в терминах шины) програмить, иногда даже несколько раз, если нужное значение достигается изменениями 1 -> 0. Некоторые вещи типа JFFS юзали такое "допрограммливание" для служебных целей и разгона эффективности. В NAND шина иная - прямой байтовой адресации нет, поэтому же из него нельзя код напрямую запускать, так что работа юнитами с страницу как минимальный адресуемый юнит. И PROGRAM идет для страницы (обычно несколько кб, например, 2...8, плюс-минус). Можно ли (до)програмливать страницу несколько раз - от чипа зависит. Современные MLC делают это чуть сложнее ибо в ячейке более 1 бита. Но идея остается, ERASE сносит большой блок в дефолтное состояние, PROGRAM шьет то что на самом деле хотели, но вот трюки с побитовой дозаписью в уже програмленый регион - там отваливаются, в силу нетривиальности обсчета для много битов на ячейку (появляется соображение как уровни заряда в биты мапятся и какие transition валидные) и многие чипы это не поддреживают. ERASE FAIL: после ERASE не все биты блока "1". В этом случае будет ремап на блок из резерва. PROGRAM FAIL: после PROGRAM не совпало с записываемым. Иногда стертое состояние может быть инвертированым, и в вон тех переходах 1 и 0 стоит поменять местами. Скажем для TRIM специфицировано что очищеный сектор - "все нули". Это по минимуму делается тривиальной инверсией. У современных емких флех еще много загонов на тему read disturbance, того факта что нельзя писать повторяющиеся паттерны в соседние ячейки из-за взаимовлияния и проч, так что фирмвара иногда делает "регенерацию" почти как DRAM, может требоваться рандомизация паттерна, чтобы BER не зашкалил, и проч. > Нельзя только перезаписать 0->1, тут придётся сначала вычитать страницу, > потом её стереть, и только потом на место единичек записать нужные данные ;) На самом деле все чуть сложнее. См. выше. И стереть придется ERASEBLOCK в котором дочерта страниц. А страница - минимально адресуемый юнит - у NAND шина не может байты "напрямую", там адрес и данные по очереди. > Это свойство как раз и используют при реализации ремапов и оно глючит ну ооочень редко. Я видел минимум несколько разлетов транслятора в флехах и SD картах. SSD менее халтурно сделаны и ведут себя поприличнее. > Если производитель в прошивке накосячил, или страничка для транзакций померла как раз > во время ремапа. Или еще можно питание сдернуть во время фоновых операций, без предупреждения накопителя - и получить очень неприятный сюрприз за это. > На практике, даже начинающие программисты для микроконтроллеров очень > легко делают надёжный код, используя это свойство флеша. Глюканёт такой код > только когда помрёт страница флеша. Так, посмеяться... я умею програмить МК. И програмил простой "flash FS". Так что вы неплохо покапитанили :). Но у МК - NOR, он неубиваемый и адресуемый напрямую. NAND намного хлипче и адресуем в общем случае странично. В МК и вообще NOR иногда тоже бывает page для ускорения операции записи, всей группой байты PROGRAM'ить немного быстрее. > Там иногда 1%, 3%, ну бывает 5% и 10% максимум (не у > всех). А хотелось бы больше. Ну я себе Debian на RAW NAND в немолодой девайсине загнал, там у UBI сколько не жалко, столько и выделяешь под резерв. Но у меня там SLC NAND был - но его 256 метров на все, впрочем, дебиан по моим лекалам занял процентов 50 вместе с 100 мегами списка пакетов (он неплохо жмется). > При использовании TRIM (или при использовании FS с закольцовыванием как в f2fs/nil2fs) > ресурс износа примерно выравнивается по всему диску. Основная фича TRIM - то что фирмвар может pre-ERASE'ануть блоки, и при записи не надо будет ждать (весьма неспешную) операцию ERASE. Это основательно разгоняет накопитель, да и GC получает больше маневрового резерва и может оптимальнее работать. Без TRIM он не знает что используется и считает всю площадь используемой, мучая некий небольшой маневровый резерв. Что субоптимально по скорости и числу операций. > Конечно может отдельный сектор умереть и на такой случай ремап 3% - ну прям офигенно много. Да вот мереть может сразу всем eraseblock-ом (если после ERASE не все биты стерлись, он меняется на резервный). А они здоровые, сильно много резервировать жаба удушит. И да, всего 1 нестершийся бит отправит нафиг всю 4 и более меговую тушку в аут. > Но по факту страницы на флешках изношены неравномерно, т.к. на диске ФС > FAT без TRIM и очень быстро укатываются конкретные "горячие" области диска В UBI даже можно выбирать какая разница допустима. Тут правда стоит сказать что оно в лине только SLC "хорошо" умеет а для MLC его никогда как следует не доделывали так что "translation layer" из него довольно базовый. > (например, FAT-таблица). Может что-то там и не выравнено по границам erase-block, > но это уже не так важно (ну в пару раз уменьшится ресурс, см выше). Основной повод выравнивать на Eraseblock - чтобы вместе с активно кантуемым регионом типа фат не отлетело бы в страну вечной охоты что-то супер критичное типа Partition. У FAT то две копии, и можно из второй починить. Но если у вас партишн попортится - то чего? Ага, у юзера круглые глаза - как это - нет ФС?! > ещё огого), а у контроллера ремапы кончились! Они все ушли на резервирование > "горячих областей" диска, а оставшаяся часть имеет ещё ого-го какой ресурс. Ну оно как бы tradeoff и зависит от степени тупости фирмвари. > Да, ремап работает! Если бы он не работал - флешки бы умирали > за неделю ;) примерно как умирают флешки из китая (там видимо > пара секторов всего для ремапа). Как альтернатива у меня есть флеха которая просто сыпется по всей площади - не утруждаясь возвратом IO error. Она нормально читается, стирается и пишется. Но через пару недель на полочке заряд утекает настолько что FEC видимо не выдюживает, но io error оно не возвращает. Вместо этого может покормить ФС трухой. Btrfs с DUP (2 копии на 1 девайс) такой подарок стебно чинит, демонстрируя мощь теорвера крутанутого в свою польщу. > Но тут проблема - на флешках FAT и без TRIM :( Поэтому > "выровнять" ресурс записи по всей флешке нереально! SD карты (и eMMC) кстати TRIM прекрасно умеют, почти все. Только надо контроллер MMC HCI для этого. Всякие одноплатники прекрасно это все могут - как и сервисные команды покидать. Равно как и МК (SD еще бонусом умеет работать по SPI, так что минимальный интерфейс позволяющий покидать "левые" команды - 4 провода по сути). У SD есть еще всякие весьма прикольные команды, типа превращения карты в ReadOnly, включая перманентный (это часть спеков SD). > Сейчас уже есть SSD, у которых начало диска (первые пару гигабайт) имеют > прям очень большой ресурс записи. А остальная часть - ну сколько > там выдал TLC/QLC... Могут поставить SLC + TLC/QLC но пойнт вот именно того все же не совсем очевиден. В SLC еще бывает модно хранить служебку + кеш (SLC быстрее пишется). А потом уже в фоне отливать с SLC на MLC. Т.е. запись быстро ухает в SLC, выдерживающий дофига перезаписи, а потом уже распределяется в хлипкий MLC с leveling и проч. > Думаю, что у флешек подобный механизм используется очень давно как раз под > FAT-таблицы. Но видимо не всегда помогает ;) Это все очень фирмварозависимо. И в общем то обычный FTL норм с FAT должен справляться, для него это в общем то очередные записи. К тому же такое допущение все нагибает если юзер отреформатит в exFAT/NTFS/...
	Ответить | Правка | Наверх | Cообщить модератору

	80. Скрыто модератором	+/–
	Сообщение от Аноним (61), 13-Дек-23, 23:11
	> SD карты (и eMMC) кстати TRIM прекрасно умеют, почти все. Только надо контроллер MMC HCI для этого. Это понятно, что умеют. Только на ПК такое не прокатит. Андроид для SD тоже не использует (может, но там FAT-only). Для mmc наверное может использовать, но у меня вот лежит старый андроид-телефон и там discard ни у одного раздела нет... В итоге они конечно умеют, но похоже никому ненужно. Кстати, как-то mmc на электронной книжке сони была возвращена к жизни перезаписью данных в двух убитых блоках. Блоки появились из-за того, что аккумулятор был высажен в 0. MMC сначалу вроде бы была Read-Only, но когда dd на чтение вернула error, блоки были перезаписаны, книжка вернулась к жизни. И на всякий случай была перешита из полного образа. > Основная фича TRIM - то что фирмвар может pre-ERASE'ануть блоки, и при записи не надо будет ждать ИМХО, это побочный эффект. > Без TRIM он не знает что используется и считает всю площадь используемой, Правильно. Без TRIM не получится контролировать износ страниц flash. В случае TLC и более поздних - это прям критичная операция. И если износ страниц становится для контроллера приоритетом, то куда и что контроллер пишет... вообще непонятно. >> Думаю, что у флешек подобный механизм используется очень давно как раз под >> FAT-таблицы. Но видимо не всегда помогает ;) > Это все очень фирмварозависимо. И в общем то обычный FTL норм с FAT должен справляться, для него это в общем то очередные записи. Я на конкретном способе/алгоритме не настаиваю, но очевидно, что какой-то способ увеличения ресурса есть. У меня было так. Флешка проработала лет 5 и я решил, что таблица разделов мне не нужна и был создан FAT прям с нулевого сектора. Флешки хватило на пару недель и она успешно свалилась в read-only. Потом была перепрошита и снова превращена в один большой FAT-диск без таблицы разделов. После этого её хватило на месяц и она опять свалилась в read-only. После этого было решено не трогать расположение FAT и флешка проработала ещё года 3... После этого она опять свалилась в read-only, была перепрошита уже какой-то китайской утилитой с увеличением количества резервных блоков (ёмкость стала чуток меньше). Ну после этого ещё года 2-3 проработала. Недавно опять свалилась в RO, пока непонятно чем всё закончится. Но думается мне, что увеличение резервной области позволило бы перешивать флешку пореже...
	Ответить | Правка | Наверх | Cообщить модератору

	100. Скрыто модератором	+/–
	Сообщение от Аноним (-), 15-Дек-23, 01:08
	> Это понятно, что умеют. Только на ПК такое не прокатит. По простому да: USB readers непрозрачный bridge, не являющийся MMC HCI, послать команды в карту не получится. Зато одноплатники с линем - запросто. Любая десятибаксовая байда на allwinner, малина или что там - mmc host до кучи. Чуть не дешевле ридера, бонусом еще эвон сколько мозгов, проц, линух... а если ЭТИМ захочется косплеить mass storage, взять железку с USB-OTG да вгрузить в лине g_mass_storage. Будет весьма стебный "картридер" - с линухом на борту. > Андроид для SD тоже не использует (может, но там FAT-only). Вероятно в FAT никто не сподвигся его запатчить на тему TRIM деаллоцированых регионов. > Для mmc наверное может использовать, но у меня вот лежит старый андроид-телефон и там > discard ни у одного раздела нет... А у меня - нормальные одноплатники, с нормальным линухом (Debian) и MMC HCI. Там все это прекрасно работает. Т.е. я зацепил btrfs с trim - и, вот, работает. Их недавний async discard был очень в тему, ибо у sd/mmc trim не особо быстрый как команда бывает. Технически большая часть карт и eMMC реагируют на TRIM как и SSDшники, т.е. затирая нолями регион. В регистрах дескриптора карты (их в лине с MMC HCI можно посмотреть) даже обычно прописано нечто что видимо является по смыслу "eraseblock". > В итоге они конечно умеют, но похоже никому ненужно. Отучаемся говорить за всех (с). > был высажен в 0. MMC сначалу вроде бы была Read-Only, но > когда dd на чтение вернула error, блоки были перезаписаны, книжка вернулась > к жизни. И на всякий случай была перешита из полного образа. Это видимо некий взбрык контроллера. А так у SD/eMMC есть специфичные фичи, можно затребовать ReadOnly явно. При том это односторонняя операция, карта должна запомнить это. Это не снимается, карта будет навечно readonly по спекам. Наверное сервисными операциями с контроллером можно это сшибить попробовать - но это вендорспецифично и без гарантий. По спекам вот так. >> Основная фича TRIM - то что фирмвар может pre-ERASE'ануть блоки > ИМХО, это побочный эффект. Это 1) Разгон скорости записи, не надо ждать завершение тормозного Erase т.к. его асинхронно в фоне заранее сделали. 2) Намного больше маневрового места для GC/WearLeveling и оптимальнее их работа. > Правильно. Без TRIM не получится контролировать износ страниц flash. И запись - особенно если писать много - тормознее. Если pre-erase не сделан, значит, вы подождете выполнения ERASE при записи. Слив скорость записи на этом. Есть разница во времени "data xfer -> ERASE -> program" VS "data xfer -> program". На одну (тормозную!) операцию меньше при записи. > В случае TLC и более поздних - это прям критичная операция. И если износ > страниц становится для контроллера приоритетом, то куда и что контроллер пишет... > вообще непонятно. Да оно во всех в общем то - весьма желательно. По ресурсу и скорости. > Я на конкретном способе/алгоритме не настаиваю, но очевидно, что какой-то способ увеличения > ресурса есть. FTL делает что-то типа copy-on-write, у него есть логические адреса, а есть физические, и есть таблицы которые описывают соответствие. FAT сейчас может быть в этом физическом блоке флеша, а при следующей записи - в совсем другом. И так далее. А одна из причин по которым дергать питание на ходу чревато это апдейт вот этой таблицы. Если она слетит (это то что и называют транслятором) - результат "не очень", все блоки перетасованы и рекавери этого "по простому" уже не вариант. Некоторые датареки умеют в перестройку транслятора, но они know how не любят делиться, они этим зарабатывают. > ещё года 2-3 проработала. Недавно опять свалилась в RO, пока непонятно > чем всё закончится. Но думается мне, что увеличение резервной области позволило > бы перешивать флешку пореже... Это вполне вероятно. Потому что уход в readonly - типовая реакция на окончание резервов для ремапа. И вот еще что, если вы делаете полный ERASE с стиранием bad block markers, вы несколько нарываетесь ибо сыпучие блоки могут таки стереться нормально, но надолго их не хватит, они осыпятся - и довольно быстро отминусуют собой резерв. Это стоит понимать. В ряде случаев вообше ERASE может за 2-3 попытки прокатить. Но если это так - ячейки блока уже "не в форме" и так можно нарваться на потерю данных. В случае RAW NAND эта механика более видна, но это и делает нанд очень гиморным :)
	Ответить | Правка | Наверх | Cообщить модератору

	76. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 13-Дек-23, 21:26
	> Для флешек/SD это очень важно, для первых SSD тоже была важно. Ну да. Лучше не проверять насколько фирмвара SSD с этим справится. > Но думаю так - если флешка заявила сектор 512 байт, то самое > главное в прошивке учтено: последовательная запись нескольких секторов приведёт к перезаписи > одной страницы. Тем не менее, если скажем 4K-блок ФС попал на пересечение страниц (в идеале тоже могут быть 4К, хотя у разных флех разное, это самый простой пример) - ради 1 блока придется ворочать 2 страницы. А в фабричном формате - одну. Откуда и фэйл с скоростью random write. > Тогда ресурс снизится ну раза в 2 (вместо одного > блока будет перезаписано 2; fat-таблица в любом случае с примерно одинаковой > интесивностью перезапиывается, а размер кластера в FAT большой. На самом деле что угодно может быть - очень зависит от логики фирмвари. Производителей и версий оной легион, и их поведение совпадать не обязано. > ИМХО, для многих современных SSD-контроллеров ВСЕ (!!!) данные проходит через remap В флеш вообще нельзя произвести запись без remap. У флеша есть "erase" и "program" - там вообще нет такого понятия как перезапись. При том erase - огромным блоком, у современных 4 мега и более может быть. А program - постранично, но после записи очистить можно только всем скопом - для eraseblock'а. Это связано с топологией кристалла, стирать сразу группой экономичнее по проводам и транзисторам, ячейка меньше площади занимает (по сравнению с произвольно адресуемым EEPROM где стирание и прогрммирование возможно для каждого байта отдельно). Поэтому совершенно любая штука вывешивающая якобы работу с якобы секторами делает нехилую трансляцию by design. А слет транслятора - довольно фатальный факап. > (после записи часто переносится/"уплотняется", потом ещё стирание явно идёт и т.д.), Любой флешовый девайс примерно так работает: у флеша eraseblocks немеряные, а страницы очистить можно только стиранием всего eraseblock. В продвинутых контроллерах несколько каналов и они любят интерливинг операций на эн каналов для скорости. Это дает старт понятию EraseGroup, когда операции ворочают для скорости сразу с несколькими чипами - параллельно на всех каналах. Erase довольно медленная операция, это разгоняет скорость в N раз. По той же причине trim важен - позволяет GC фирмвари почистить eraseblocks в фоне, не нарываясь на паршивую скорость операции ERASE при записи - оно сделано заранее. Так что для более продвинутых SSD может иметь некий смысл попытаться выравнять партишн и /boot раздел на вот это вот. Угадать разумеется сложно, но круглые юниты типа 256 мегов имеют шанс (физически это Eraseblock * channels). Это чтобы в случае внезапного слета питания по крайней мере без партишна не остаться. Ах да, снимать питание без информирования накопителя нельзя ни в SSD, ни в флехах, ни даже в SD картах. Потому что они вот могут гонять фоновые операции. И слет питания в этот момент может вызвать конкретный факап. Хорошие контроллеры обычно это переживают, но - логгят факап, накручивая счетчик. И если что, это повод послать в гарантийке, видимо. А более поганые девайсы могут от необдуманного сдерга транслятор потерять и вот это - знатный облом. > поэтому выравнивание по границам секторов уже бессмысленно, данные никогда не попадут > на диск как тебе хотелось ;) Вообще, таки есть шансы что даже так операции фирмвари упростятся до частных случаев. Но это как повезет. Что и является заметным минусом решения - никогда не знаешь что оно откаблучит. >> Когда контроллер будет RMW на копии фата гонять, питание слетит, это записаться не успеет > На флеш (raw flash) есть очень надёжный механизм коммитов. Там есть Erase и Program. Им самим по себе вообще все вон то неведомо. Остальное делается фирмварой и уровнем транстяции. > Всегда можно побитово перезаписать 1->0, 1->1 и даже 0->0. Не так! В совсем "классическом" виде: ERASE сбрасывает все биты (всех страниц) большого ERASEBLOCK в 1 (стертый флеш читается как 0xFF). PROGRAM позволяет сделать из 0xFF то что хочется, но только если это переход 1 -> 0 (0xFF можно превратить во что угодно). Обратно только стиранием всего ERASEBLOCK и всей оравы в несколько мегов. Гранулярность PROGRAM и возможность дозаписи страницы - варьируется. В NOR с интерфейсом шины можно даже отдельные байты или word'ы (в терминах шины) програмить, иногда даже несколько раз, если нужное значение достигается изменениями 1 -> 0. Некоторые вещи типа JFFS юзали такое "допрограммливание" для служебных целей и разгона эффективности. В NAND шина иная - прямой байтовой адресации нет, поэтому же из него нельзя код напрямую запускать, так что работа юнитами с страницу как минимальный адресуемый юнит. И PROGRAM идет для страницы (обычно несколько кб, например, 2...8, плюс-минус). Можно ли (до)програмливать страницу несколько раз - от чипа зависит. Современные MLC делают это чуть сложнее ибо в ячейке более 1 бита. Но идея остается, ERASE сносит большой блок в дефолтное состояние, PROGRAM шьет то что на самом деле хотели, но вот трюки с побитовой дозаписью в уже програмленый регион - там отваливаются, в силу нетривиальности обсчета для много битов на ячейку (появляется соображение как уровни заряда в биты мапятся и какие transition валидные) и многие чипы это не поддреживают. ERASE FAIL: после ERASE не все биты блока "1". В этом случае будет ремап на блок из резерва. PROGRAM FAIL: после PROGRAM не совпало с записываемым. Иногда стертое состояние может быть инвертированым, и в вон тех переходах 1 и 0 стоит поменять местами. Скажем для TRIM специфицировано что очищеный сектор - "все нули". Это по минимуму делается тривиальной инверсией. У современных емких флех еще много загонов на тему read disturbance, того факта что нельзя писать повторяющиеся паттерны в соседние ячейки из-за взаимовлияния и проч, так что фирмвара иногда делает "регенерацию" почти как DRAM, может требоваться рандомизация паттерна, чтобы BER не зашкалил, и проч. > Нельзя только перезаписать 0->1, тут придётся сначала вычитать страницу, > потом её стереть, и только потом на место единичек записать нужные данные ;) На самом деле все чуть сложнее. См. выше. И стереть придется ERASEBLOCK в котором дочерта страниц. А страница - минимально адресуемый юнит - у NAND шина не может байты "напрямую", там адрес и данные по очереди. > Это свойство как раз и используют при реализации ремапов и оно глючит ну ооочень редко. Я видел минимум несколько разлетов транслятора в флехах и SD картах. SSD менее халтурно сделаны и ведут себя поприличнее. > Если производитель в прошивке накосячил, или страничка для транзакций померла как раз > во время ремапа. Или еще можно питание сдернуть во время фоновых операций, без предупреждения накопителя - и получить очень неприятный сюрприз за это. > На практике, даже начинающие программисты для микроконтроллеров очень > легко делают надёжный код, используя это свойство флеша. Глюканёт такой код > только когда помрёт страница флеша. Так, посмеяться... я умею програмить МК. И програмил простой "flash FS". Так что вы неплохо покапитанили :). Но у МК - NOR, он неубиваемый и адресуемый напрямую. NAND намного хлипче и адресуем в общем случае странично. В МК и вообще NOR иногда тоже бывает page для ускорения операции записи, всей группой байты PROGRAM'ить немного быстрее. > Там иногда 1%, 3%, ну бывает 5% и 10% максимум (не у > всех). А хотелось бы больше. Ну я себе Debian на RAW NAND в немолодой девайсине загнал, там у UBI сколько не жалко, столько и выделяешь под резерв. Но у меня там SLC NAND был - но его 256 метров на все, впрочем, дебиан по моим лекалам занял процентов 50 вместе с 100 мегами списка пакетов (он неплохо жмется). > При использовании TRIM (или при использовании FS с закольцовыванием как в f2fs/nil2fs) > ресурс износа примерно выравнивается по всему диску. Основная фича TRIM - то что фирмвар может pre-ERASE'ануть блоки, и при записи не надо будет ждать (весьма неспешную) операцию ERASE. Это основательно разгоняет накопитель, да и GC получает больше маневрового резерва и может оптимальнее работать. Без TRIM он не знает что используется и считает всю площадь используемой, мучая некий небольшой маневровый резерв. Что субоптимально по скорости и числу операций. > Конечно может отдельный сектор умереть и на такой случай ремап 3% - ну прям офигенно много. Да вот мереть может сразу всем eraseblock-ом (если после ERASE не все биты стерлись, он меняется на резервный). А они здоровые, сильно много резервировать жаба удушит. И да, всего 1 нестершийся бит отправит нафиг всю 4 и более меговую тушку в аут. > Но по факту страницы на флешках изношены неравномерно, т.к. на диске ФС > FAT без TRIM и очень быстро укатываются конкретные "горячие" области диска В UBI даже можно выбирать какая разница допустима. Тут правда стоит сказать что оно в лине только SLC "хорошо" умеет а для MLC его никогда как следует не доделывали так что "translation layer" из него довольно базовый. > (например, FAT-таблица). Может что-то там и не выравнено по границам erase-block, > но это уже не так важно (ну в пару раз уменьшится ресурс, см выше). Основной повод выравнивать на Eraseblock - чтобы вместе с активно кантуемым регионом типа фат не отлетело бы в страну вечной охоты что-то супер критичное типа Partition. У FAT то две копии, и можно из второй починить. Но если у вас партишн попортится - то чего? Ага, у юзера круглые глаза - как это - нет ФС?! > ещё огого), а у контроллера ремапы кончились! Они все ушли на резервирование > "горячих областей" диска, а оставшаяся часть имеет ещё ого-го какой ресурс. Ну оно как бы tradeoff и зависит от степени тупости фирмвари. > Да, ремап работает! Если бы он не работал - флешки бы умирали > за неделю ;) примерно как умирают флешки из китая (там видимо > пара секторов всего для ремапа). Как альтернатива у меня есть флеха которая просто сыпется по всей площади - не утруждаясь возвратом IO error. Она нормально читается, стирается и пишется. Но через пару недель на полочке заряд утекает настолько что FEC видимо не выдюживает, но io error оно не возвращает. Вместо этого может покормить ФС трухой. Btrfs с DUP (2 копии на 1 девайс) такой подарок стебно чинит, демонстрируя мощь теорвера крутанутого в свою польщу. > Но тут проблема - на флешках FAT и без TRIM :( Поэтому > "выровнять" ресурс записи по всей флешке нереально! SD карты (и eMMC) кстати TRIM прекрасно умеют, почти все. Только надо контроллер MMC HCI для этого. Всякие одноплатники прекрасно это все могут - как и сервисные команды покидать. Равно как и МК (SD еще бонусом умеет работать по SPI, так что минимальный интерфейс позволяющий покидать "левые" команды - 4 провода по сути). У SD есть еще всякие весьма прикольные команды, типа превращения карты в ReadOnly, включая перманентный (это часть спеков SD). > Сейчас уже есть SSD, у которых начало диска (первые пару гигабайт) имеют > прям очень большой ресурс записи. А остальная часть - ну сколько > там выдал TLC/QLC... Могут поставить SLC + TLC/QLC но пойнт вот именно того все же не совсем очевиден. В SLC еще бывает модно хранить служебку + кеш (SLC быстрее пишется). А потом уже в фоне отливать с SLC на MLC. Т.е. запись быстро ухает в SLC, выдерживающий дофига перезаписи, а потом уже распределяется в хлипкий MLC с leveling и проч. > Думаю, что у флешек подобный механизм используется очень давно как раз под > FAT-таблицы. Но видимо не всегда помогает ;) Это все очень фирмварозависимо. И в общем то обычный FTL норм с FAT должен справляться, для него это в общем то очередные записи. К тому же такое допущение все нагибает если юзер отреформатит в exFAT/NTFS/...
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	88. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Kuromi (ok), 14-Дек-23, 16:20
	> ИМХО, для многих современных SSD-контроллеров ВСЕ (!!!) данные проходит через remap   > (после записи часто переносится/"уплотняется", потом ещё стирание явно идёт и т.д.), > поэтому выравнивание по границам секторов уже бессмысленно, данные никогда не попадут > на диск как тебе хотелось ;) > Сейчас уже есть SSD, у которых начало диска (первые пару гигабайт) имеют > прям очень большой ресурс записи. А остальная часть - ну сколько > там выдал TLC/QLC... > Думаю, что у флешек подобный механизм используется очень давно как раз под > FAT-таблицы. Но видимо не всегда помогает ;) Если в SSD встроен кэш (статический+динамический (как в у Самсунг)) или есть SLC mode, который сейчас суют во все диски с QLC точно, иначе они тормозили бы, то там и правда все данные сначала пишутся в одно место, а потом переписываются или вообще уплотняются с перезаписью. Даже статический кэш сейчас это обычно гигабайт 4-20 (зависит от модели и объема само собой), так что выделить некоторую его часть под хранение самого начала диска вполне себе разумная идея. И еще раз встает вопрос о том насколько глупой была затея использовать FAT в качестве файловой системы на флеш, просто слов нет.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	73. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Вася (??), 13-Дек-23, 20:04
	>Контроллер там живее всех живых, если умирает контроллер - устройство вообще признаков жизни не подаёт! Такое ну оооочень редко встречается. редко встречается??? я ниразу не видел чтобы флеш память накрылась внезапно- только когда выжрала ресурс и заблокировалась запись. Зато у меня есть несколько знакомых (не 1 или 2, а больше) у которых сдох ссд с концами за долго до исчерпания ресурса сдох контроллер. У меня тоже сдох контроллер на нвме ссд у которого здоровья было 80% и данные все накрылись. Теперь я когда знакомым собираю комп обязательно ставлю жесткий диск и говрю хранить все важные данные только нанём и бакапить в облако. ССД оказались не хранилищем информации, а всего лишь временным кэшем для системы вроде оперативки, но дешевле и менее надёжным.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	84. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (84), 14-Дек-23, 13:44
	> я ниразу не видел чтобы флеш память накрылась внезапно- только когда выжрала ресурс и заблокировалась запись Я именно об этом и написал. >> заканчиается место для ремапов и контроллер переводит диск в режим read-only. Ну согласен... на SSD стараются не допускать, чтобы флеш-память использовалась после исчерпания заявленого производителем flash-памяти ресурса. Поэтому контроллер может подсчитать количество записей и сказать, что хватит писать. А bad-блоков по факту пока немного. ХЗ насколько это правда, но похоже, что многие производители SSD делают именно так. > за долго до исчерпания ресурса сдох контроллер. У меня вот SSD уже 10 лет стоит, ресурс 98%, записано ~30ТБ. Основная система на нём крутится. Он сдохнет задолго до 0%, это очевидно ;) Если бы я на него торренты качал, или СУБД на нём использовал активно... то он бы уже свалился в read-only лет 5 назад.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (96), 14-Дек-23, 20:09
	> Если бы я на него торренты качал Это жеж гораздо более лёгкая нагрузка, чем типичная для системного диска.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от torvn77 (ok), 16-Дек-23, 22:20
	> У меня вот SSD уже 10 лет стоит, ресурс 98%, записано ~30ТБ. Не знаю как современные контроллеры, а раньше контроллер убивался достаточно просто.   Несколько раз отлрматировал диск с посекторной записью и всё, контроллер превращается в глючный постоянно повисающий утюг.   Если не нравится форматирование то можно взять другой диск и "забекапить все файлы" или несколько раз снять образ.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	109. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от torvn77 (ok), 16-Дек-23, 22:11
	>Теперь я когда знакомым собираю комп обязательно ставлю жесткий диск и говрю хранить все важные данные только нанём Будто и у hdd он сдохнуть не может.   Единственный плюс в том что hdd в теории должкн переживать длительное отключение, в то время как современная память теряет заряд за несколько месяцев или даже недель.   > и бакапить в облако. Надо делать либо raid10, либо raid 5 или 6.   (помимо резервирования уменьшается скорость чтения с отдельного диска и как следствие меньше греется контроллер)
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	83. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (83), 14-Дек-23, 11:57
	> Когда слишком много bad-block'ов появляется - заканчиается место для ремапов и контроллер переводит диск в режим read-only Блин хоть бы раз увидеть такое живъем. Обычно либо не определяется вообще, либо читается и пишется но некоторые куски не читаются(либо читаются но со скоростью в несколько килобайт и то при помощи танцев с бубном)
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	89. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Kuromi (ok), 14-Дек-23, 16:23
	>> Когда слишком много bad-block'ов появляется - заканчиается место для ремапов и контроллер переводит диск в режим read-only > Блин хоть бы раз увидеть такое живъем. Обычно либо не определяется вообще, > либо читается и пишется но некоторые куски не читаются(либо читаются но > со скоростью в несколько килобайт и то при помощи танцев с > бубном) Было было. У меня так пара карт памяти безмолвно перешли в режим read-only, причем когда ты записываешь файл на такую флешку оно вроде как все пишется, только обнови  каталог и там пусто. Это очень прикольно когда ты ходишь с фотоаппаратом и мертвой картой. Самсунговские NVME Evo Plus  из-за бага в прошивке в прошлом году массово уезжали в read-only с ресурсом 0% (причем почти новые).
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Опубликована платформа SEF для программно управляемых Flash-..."	+1 +/–
	Сообщение от Аноним (-), 13-Дек-23, 11:57
	> Идея в том чтобы вытащить всю ту логику что сейчас делает контроллер, вроде выравнивания > износа в драйвер на хосте. С одной стороны это хорошо, например позволит избавиться > от слоев трансляции реальных адресов по которым лежать данные на флеше в "виртуальные", > что выдает контроллер симулируя что-то HDD-подобное, например, позволит более четко > понимать состояние флеш-памяти, степень износа. С другйо стороны потребуются новые > файловые системы, и слегка оптимизированными вроде f2fs тут не отделаешься, потребуется > что-то вроде JFFS2 чтобы разумно распоряжаться ресурсами NAND. Так там же FTL выложен. Так можно косплеить хоть блочный девайс, или что там удобно. Ну вон UBI косплеит безошибочный и линейный регион для NAND. И современные файлухи с CoW довольно хорошо ложатся на что-то такое. А если в Zoned умеют - так и вообще почти все готово, осталось интерфейсы для таких взаимодействий как-то устаканить. Ну как, CoW в принципе все равно куда писать и добавить критерий типа "наименее протертый регион" вполне можно.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	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
	> Там запретили асинхронный TRIM (т.е. команды на TRIM идут вместе обычными на > чтение\запись данных) который в Линуксе задействуется когда включен continuous TRIM. Ну как бы если фимрварь заявляет некую команду и не имплементит ее корректно, это баг фирмвари. А у самсуня вообще глюкавых железок - есть. Достаточно посмотреть список quirks в майнлайне на это все. > Вот это глючило, да, оказалось что многие Самсунги хоть и говорят что > могут одновременно тримить и работать как обычно но на деле очень > не любят, у других производителей такого не было замечено. Да у гнусмуса в целом руки - кривые. Как у фирмы. Потому что наваливает на своих галерных рабов больше чем они реально могут. Они и гребут как умеют. В фирмвари накопителей за это разумеется отливается. Как впрочем и в ФС. > Прикол в том что continuous TRIM вообще нигде кроме Линукс не поддерживается, > да и под  Линуксом он не рекомендуется. Везде явный вызов > с большим диапазоном и ожиданием пока накопитель не почистится. Прикол в том что железки самса - одни из самых глючных. Достаточно посмтреть сколько для них воркэраундов и костылей вбили. > Условный f2fs или btrfs делает это иначе, собирает данные-кондидаты на TRIM в > фоне, а потом во время простоя их чистит. По сути мало > чем отличается от continuous, только без глюков. В случае btrfs завели некий worker-тредик, который энное время ждет и копит всякое добро - в надежде объединить регионы и проч, а при случае в фоне тримает. Так то это логично, продвинутый умный вариант "fstrim" - без ожидания команд и независимо от фич девайса. Но заметь: часть логики фирвары в результате переехала в линух. И он стал сложнее. И в целом это лучше работало - потому что там рабочие процессы лучше чем у самса. А, кроме того что самс комитит :). У меня F2FS power loss тесты не пережил и сдох буквально мигом. В максимально дурном виде когда ядро его не маунтит, а fsck не чинит. Спасибо что это тестовая файлуха была и данные не нужны. В этом деле главное вовремя прочухать когда вместо себя в кресло манекен сажать. > А вообще с TRIM всегда все сложно. В одним устройствах он может > вызывать полный стоп на какой-то промежуток времени, устройство почти перестает отвечать > (зато быстро), Все сложно - с фирмварами живущими своими жизнями, и по мере появления продвинутых фич и роста скоростей все это стало весьма... специфично... и грабельно. > - вопрос. Последние годы их вообще ругают, что их прошивки глючат, > так сказать "победитель расслабился". Я б сказал что это довольно много лет. Чуть не с сотворения самса. Раньше они просто славились хреновой механикой, что FDD, что HDD, что CD, и проч, если диск бэдами по всей площади пошел, там даже идеальная фирмварь ничего не сделает, ну никто и не обращал внимания на фирмвару. А в SSD механики, вот, нет - облажаться не получается, так что тут уж без вариантов, большая часть шишек - им :). Сам флеш у самса кстати на удивление - получше чем у многих других. Машинам то норм пахать 25 часов в сутки, в отличие от двуногих. Но если тебе так код напишут, да еще в фирмвари...
	Ответить | Правка | Наверх | Cообщить модератору

	122. Скрыто модератором	+/–
	Сообщение от Kuromi (ok), 17-Дек-23, 23:05
	> Я б сказал что это довольно много лет. Чуть не с сотворения > самса. Раньше они просто славились хреновой механикой, что FDD, что HDD, > что CD, и проч, если диск бэдами по всей площади пошел, > там даже идеальная фирмварь ничего не сделает, ну никто и не > обращал внимания на фирмвару. А в SSD механики, вот, нет - > облажаться не получается, так что тут уж без вариантов, большая часть > шишек - им :). Сам флеш у самса кстати на удивление > - получше чем у многих других. Машинам то норм пахать 25 > часов в сутки, в отличие от двуногих. Но если тебе так > код напишут, да еще в фирмвари... Самсунг хорош хотя бы тем что их SSD без особых проблем обновляет прощивки под Линуксом. Рецепты известны, вынуть из образа бинарь и запустить, работает. С другими производителями это головняк. У WD техническая возможность есть, но нужно руками шаманить (в большей степени чем с Самсунгом), хотя рецепт есть. Не обновлть прошивки у WD - плохая идея так как у них манера выпускать в продажу накопители с сырыми прошивками которые могут умереть через пару месяцев без обновления (Wd Blue SA510 - прекрасный пример). У каких нибудь Кингстонов или Трансцендов вообще фигушки. Лучше всех был Intel, обновление из фирменной консольной утилиты идущей с сразу архивом последних прошивок.
	Ответить | Правка | Наверх | Cообщить модератору

	124. Скрыто модератором	+/–
	Сообщение от Аноним (-), 18-Дек-23, 00:28
	> Самсунг хорош хотя бы тем что их SSD без особых проблем обновляет > прощивки под Линуксом. Рецепты известны, вынуть из образа бинарь и запустить, работает. Вообще девайсы покупают не для того чтобы им прошивки обновлять, а чтобы юзать по назначению. Если утилсы для линуха есть - ну, окей, это гуд. И все же дело стоража - данные хранить. Не создавая при этом проблем. Самсы слишком часто светились в списке проблемных на мой вкус. Они умеют делать хороший флеш, но вот железка с сборе - "корейская рулетка", никогда не знаешь где накосячили замордованые галерой кодеры. > них манера выпускать в продажу накопители с сырыми прошивками которые могут > умереть через пару месяцев без обновления (Wd Blue SA510 - прекрасный > пример). У каких нибудь Кингстонов или Трансцендов вообще фигушки. Ну так если фирмваре кривое - они и поимеют немеряно возвратов по гарантии. Это простимулирует получше делать в следующий раз. Замена по гарантии - попадос по деньгам для производителя. Так даже капиталисту понятно. > Лучше всех был Intel, обновление из фирменной консольной утилиты идущей с сразу > архивом последних прошивок. Там тоже раз на раз не приходится. А интелем называли самые разные вещи. Одно время они по моему кривой вариант SandForce'а ставили и с ними тоже народ познал горя. В общем единственная константа - мир меняется. А чем является тот или иной накопитель обычно узнаем несколько поздновато, ибо статистика накапливается уже опосля. В этом смысле мудрость что бесплатный сыр достается только второй мышке - имеет некий смысл :)
	Ответить | Правка | Наверх | Cообщить модератору

	125. Скрыто модератором	+/–
	Сообщение от Kuromi (ok), 18-Дек-23, 00:36
	> Там тоже раз на раз не приходится. А интелем называли самые разные > вещи. Одно время они по моему кривой вариант SandForce'а ставили и > с ними тоже народ познал горя. В общем единственная константа - > мир меняется. А чем является тот или иной накопитель обычно узнаем > несколько поздновато, ибо статистика накапливается уже опосля. В этом смысле мудрость > что бесплатный сыр достается только второй мышке - имеет некий смысл > :) А у Интолла было две, условно, линейки, тру Интолл и "как-бы" Интолл подешевле, и корпоративные продукты - это отдельно. У меня было Intel 760p, вот он был тру (вроде как). Поделки на сендфорсе у Интелл тоже были, но народ не купился. А потом интолл просто ушел из SSD бизнеса, что в общем-то жаль. Даже сендфорсы у них были с кастомной прошивкой, которую они реально дорабатывали, а не логотипы меняли.
	Ответить | Правка | Наверх | Cообщить модератору

	126. Скрыто модератором	+/–
	Сообщение от Аноним (96), 18-Дек-23, 04:12
	> А потом интолл просто ушел из SSD бизнеса, что в общем-то жаль. Он его продал, теперь это Solidigm. https://www.anandtech.com/show/17134/intel-sells-ssd-busines...
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Kuromi (ok), 14-Дек-23, 16:28
	>> Зато (голой) скорости прибавится вполне вероятно > Учитывая что для возни с банками твердотельника выделен контроллер( отдельный многоядерный > проц со специфическими аппаратными блоками ) и отдельная ОЗУ, то перенос > всего этого на сторону компа и ОС относительно "голой" прошивки едва > ли повысит скорость работы при прочих равных( включая нагрузку на ЦП > ) А вы уверены что они выкинут вообще все, включая процы контроллера? Прошлый раз когда я читал про вот такие подвижку в сторону осовременивания флеш-памяти там четко именно таблица трансляции была означена источником всего зла. Мол вот уберем, разгрузим контроллер и будет летать. Часть функций можно оставить. Отдельная ОЗУ в основном нужна для хранения этой самой таблицы и может чуть чуть самого кэша. Контроллер для совсем своих нужд часто использует встроенную свою ОЗУ, так например происходит на dram-less SATA SSD - там по HMB памяти не попросить.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	74. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (74), 13-Дек-23, 21:16
	Ну хоть одна здравая идея. Или вендоры настолько косячат, что силы молчать нет? Просто аналогичная боль могла (и есть) с g-list и p-list у HDD,  однако, тут полная молчанка за редкими исключениями, вроде, тем на форумах https://superuser.com/questions/1612557/how-to-move-g-list-b... и низовых технологических утилит, которые из простых смертных мало кто видел.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

2. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
Сообщение от нокия (?), 12-Дек-23, 23:51
всё понятно. где купить?
Ответить | Правка | Наверх | Cообщить модератору

	4. "Опубликована платформа SEF для программно управляемых Flash-..."	+1 +/–
	Сообщение от Аноним (3), 13-Дек-23, 00:18
	Обращайтесь в KIOXIA, они выпускают https://www.prnewswire.com/news-releases/software-enabled-fl...
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 13-Дек-23, 00:26
	Ты хотел сказать "скачать и собрать"? Насколько я понал - то ты подключаешь кучу разномастных накопителей и получаешь виртуальную флешку. И там играться с параметрами использования, алгоритмами и всем прочим.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

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

	60. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (3), 13-Дек-23, 16:24
	Нет, нужны специальные накопители с поддержкой этой фичи. В существующих накопителях контроллер просто не поймёт, чего от него хотят.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

6. "Опубликована платформа SEF для программно управляемых Flash-..."	–13 +/–
Сообщение от Шарп (ok), 13-Дек-23, 00:24
>инструментария написаны на языке Си Жаль. А ведь технология подавала надежды. Но с таким инструментарием оно способно только на создание CVE.
Ответить | Правка | Наверх | Cообщить модератору

	9. "Опубликована платформа SEF для программно управляемых Flash-..."	+1 +/–
	Сообщение от Аноним (-), 13-Дек-23, 00:29
	> Но с таким инструментарием оно способно только на создание CVE. Зато каких эпичных! Просто представь лицо юзера, когда вся порнуха исчезнет с его home-NAS, заботливо собранного из хддшек и флешек найденных на помойке! Есть надежда, что под БСД лицензией код будет более академическим, чем в ядре линукса. И что они используют какуюто методологию типа мисры или хотя бы пишут тесты.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Опубликована платформа SEF для программно управляемых Flash-..."	–2 +/–
	Сообщение от nox. (?), 13-Дек-23, 07:07
	> более академическим Это когда своим трудом не могут заработать, поэтому учат студентов?
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от 1 (??), 13-Дек-23, 11:07
	учить студентов - тоже работа. А так ... это же со времён СССР - "Не можешь работать - учи, не можешь учить - управляй"
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (52), 13-Дек-23, 14:04
	В ядре Линукса код используется практически, а академический так и остаётся в академиях.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	44. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 13-Дек-23, 11:58
	> Жаль. А ведь технология подавала надежды. Но с таким инструментарием оно способно > только на создание CVE. Ну ты можешь на шарпе написать фирмварь накопителя и системный софт. Посмотрим что получится как раз.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

8. "Опубликована платформа SEF для программно управляемых Flash-..."	–3 +/–
Сообщение от Аноним (8), 13-Дек-23, 00:27
> первый выпуск открытой платформы для программно управляемых Flash-накопителей SEF (Software Enabled Flash) который отправляет zfs и прочие ненужные усложнённые фс на свалку истории
Ответить | Правка | Наверх | Cообщить модератору

	45. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 13-Дек-23, 12:01
	> который отправляет zfs и прочие ненужные усложнённые фс на свалку истории Глядя на то как btrfs запилил поддержку Zoned - на минуточку, это почти ответка к тому интерфейсу уже и есть :)) Если что - Zoned применяется в том числе и флешовыми девайсами как более тонкий уровень в контроллере, где ФС/ОС явно в курсе что у накопителя есть регионы, в которые можно только последовательную запись, а чтобы перезаписать - надо очистить зону. Это так то представление семантики операций Erase/Program флеша через довольно тонкий уровень ремапа, хотя черепице тоже подошло.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 13-Дек-23, 14:14
	> Это так то представление семантики операций Erase/Program флеша через довольно тонкий уровень ремапа в btrfs cow само по себе прекрасно ложится на флеши - запись всегда в новую область последовательно а вот всякие виртуальные устройства с разным приоритетом и контрольные суммы - нафиг не нужны в фс, SEF всё сделает
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (66), 13-Дек-23, 17:09
	> в btrfs cow само по себе прекрасно ложится на флеши - запись > всегда в новую область последовательно а вот всякие виртуальные устройства с > разным приоритетом и контрольные суммы - нафиг не нужны в фс, > SEF всё сделает В случае btrfs чексуммы дают дополнительные возможности. Скажем, копий может быть и 2 (или даже 3 или 4!) - и при факапе чексуммы можно еще и закопировать блок с другого устройства. Сделав SelfHeal. А как вы чексуммами вон там что-то такое организуете? Вы же не можете на том уровне уповать что девайсов в системе гарантированно 2 или более? Это только вон там ФС знает, можно так было в конкретной системе - или нет. И прочие RAID и ко - в ФС все же лучше делаются: можно динамически отращивать или уменьшать емкость, прям на ходу, добавлением или выниманием девайса. Иногда таки удобно.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 13-Дек-23, 18:40
	> В случае btrfs чексуммы дают дополнительные возможности. Скажем, копий может быть и 2 (или даже 3 или 4!) - и при факапе чексуммы можно еще и закопировать блок с другого устройства. а смысл держать 4 копии в одном месте - есть распределённые фс, а так у тебя электричество кончится и ни одной не прочитаешь > можно динамически отращивать или уменьшать емкость, прям на ходу, добавлением или выниманием девайса. с SEF скорей всего так тоже можно иначе в чём смыл его "гипермасштабируемости"
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 13-Дек-23, 21:57
	> а смысл держать 4 копии в одном месте - есть распределённые фс, > а так у тебя электричество кончится и ни одной не прочитаешь Ну например если есть >=4 накопителя, можно метаданные для надежности как RAID1C4 а данные что попроще, из соображений что разлет метаданных делает все сильно сложнее. А делать вот именно распределенные структуры - это весьма нишевое и специальное знание. Особенно в не слишком дурном виде. И это все же другой уровень сложности и компетенции. Я в чем-то согласен что вон то несколько нишевой случай, но если его сделали, значит это было кому-то нужно. > с SEF скорей всего так тоже можно иначе в чём смыл его > "гипермасштабируемости" Он что, будет знать что я пристыковал еще энные девайсы хочу вон ту или вот эту ФС туда расширить? Не очень понимаю как такое знание должно транслироваться на ТОТ уровень. Как это в ФС выглядит - это как раз понятно. "device add -> +N места". Менеджмент систем как он должен был быть с самого начала.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 14-Дек-23, 08:14
	>  Не очень понимаю как такое знание должно транслироваться на ТОТ уровень. Как это в ФС выглядит - это как раз понятно. "device add -> +N места". не понимаю в чём сложность что диск стал больше - воткнули новый диск, через cli-утилиту сказали sef-у вон от того диска приплюсуй вон к тому, тому, тому логическим, resize налету даже ext4 поддерживает
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 17-Дек-23, 22:55
	>>  Не очень понимаю как такое знание должно транслироваться на ТОТ уровень. >> Как это в ФС выглядит - это как раз понятно. "device add -> +N места". > не понимаю в чём сложность что диск стал больше - воткнули новый > диск, через cli-утилиту сказали sef-у вон от того диска приплюсуй вон > к тому, тому, тому логическим, resize налету даже ext4 поддерживает А данные с старого диска на новый - телепортируются? А оба диска на пару как 1 стораж? У вон тех то - "btrfs device add <what>" -> +N места в ФС. Можно и device remove, удвинет используемые данные (а не всю площадь) и можно вынуть девайс. При том - это еще и с RAID работает. Если есть девайсы на 2, 3 и 5 терабайт, это вполне сделает RAID1 cуммарным размером около 5 терабайтов. А вы так смогете? :) ...та штука врядли в курсе таких чудес инженерии и менеджмента. BigPic - не ее уровень.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 18-Дек-23, 23:44
	> А данные с старого диска на новый - телепортируются? А оба диска на пару как 1 стораж? во первых зачем телепортировать - устройства логические, ты LBA видишь снаружи, полдиска логического с одного массива нанды вторая половина с другого да и p2p dma на pcie есть
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 19-Дек-23, 01:14
	>> А данные с старого диска на новый - телепортируются? А оба диска на пару как 1 стораж? > во первых зачем телепортировать - Есть минимум 3 причины закопировать или переместить данные на другой накопитель: 1) Если старый девайс хочется вынуть из системы, т.е. "замена". 2) Load balancing. 3) Redundancy. > устройства логические, ты LBA видишь снаружи, полдиска логического с одного > массива нанды вторая половина с другого да и p2p dma на pcie есть И - чего? Это никак не адресует load balancing, миграцию данных, избыточность, изъятие накопителя с данными из системы, замену девайса на другой. Вполне обычные хотелки системного менеджмента. А заодно можно и - вот - продвинутости. Не сошелся чексум при чтении? SELF HEAL! Берется блок с другой копии. Пишется в проблемный стораж заново. Если это изредка - ну и отлично, избыточность восстановлена. Если часто - окей, сигнал что глюкастик пора менять. Так что это врядли замена вон тому. Фичесет сильно разный и уровни абстракции не те. Но вот какой zoned mode файлух и cow может на это неплохо пристроиться, видимо.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 19-Дек-23, 01:37
	> И - чего? Это никак не адресует load balancing, миграцию данных, избыточность, изъятие накопителя с данными из системы, замену девайса на другой. последний абзац новости намекает что всё это есть, мне лень погружаться
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (96), 14-Дек-23, 22:08
	> в btrfs cow само по себе прекрасно ложится на флеши На голые флеши его класть нельзя, flash translation layer для выравнивания износа всё ещё нужен, поэтому толк от последовательной записи (в смысле дружбы с флешами)... только в более лёгкой адаптации под ZNS? Насколько оно вообще хорошо ложится, показывает величина write amplification и у CoW ФС она больше, чем у других (может, из-за обычных для них наворотов типа дублирования метаданных). Для хорошего укладывания надо разделить потоки записи, тут или ZNS поможет, или, теоретически, не-CoW ФС, где у контроллера SSD остаётся подсказка, где данные горячие, а где холодные, чтобы их не смешивать в одном блоке.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	101. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 15-Дек-23, 10:21
	> Насколько оно вообще хорошо ложится, показывает величина write amplification и у CoW ФС она больше, чем у других (может, из-за обычных для них наворотов типа дублирования метаданных). дело не в cow а в том что монстрофс с cow хранят снапшоты - для пользователя кажется что диск наполовину занят а для контроллера диск забит под завязку, он в фоне перекидывает занятые блоки на новое место для выравнивания износа, это эквивалентно как если фс не поддерживает TRIM
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (96), 15-Дек-23, 11:52
	> дело не в cow а в том что монстрофс с cow хранят снапшоты Нет, это дело ещё более опциональное, чем дублирование метаданных, а коровья сущность всё-таки на write amplification влияет.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 15-Дек-23, 12:48
	> а коровья сущность всё-таки на write amplification влияет только в лучшую сторону, например специальная фс для nand ubifs - спроектирована по заказу Nokia, дураки наверно проектировали с cow :)
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (96), 15-Дек-23, 22:10
	Я с обобщениями ещё вот где напортачил. Write amplification на практике могут определять как 1. объём записи непосредственно во флеш-память, поделённый на объём записи с хоста на SSD (чаще). 2. оверхед файловой системы, без погружения ниже логических адресов (реже). И это будут два совсем разных результата (и потенциальный третий, если кто-то объединяет обе величины). > только в лучшую сторону, например специальная фс для nand ubifs - спроектирована > по заказу Nokia, дураки наверно проектировали с cow :) F2FS - более подходящий пример, она в тех же условиях, что и btrfs (не работает с сырым флешем). Про разницу в оверхеде между ними (во втором смысле) пишут так: "In contrast, btrfs has a complex implementation of the copy-on-write technique (mostly due to a push to provide more features such as snapshots and stronger data integrity) that leads to extremely high space and write amplification" [1] Ещё там, оказывается, есть приёмы для разделения горячих и холодных данных, контроллер их как-то понимает. "six major log areas to maximize the effect of hot and cold data separation" [2] [1] https://arxiv.org/pdf/1707.08514.pdf#page=3 [2] https://www.usenix.org/system/files/conference/fast15/fast15...
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 16-Дек-23, 11:38
	> Ещё там, оказывается, есть приёмы для разделения горячих и холодных данных, контроллер их как-то понимает. тоже мне бином ньютона - что мешает считать обращения к логическим блокам а не только к физическим, горячие логические блоки размещают в SLC как вариант - у них ресурс на порядки больше
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от torvn77 (ok), 16-Дек-23, 22:33
	> и контрольные суммы - нафиг не нужны в фс, > SEF всё сделает Не согласен, очень удобно когда ФС знает что и как прочиталось и может сама откорректировать ошибку.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	114. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 17-Дек-23, 11:31
	> очень удобно когда ФС знает что и как прочиталось и может сама откорректировать ошибку можешь взять результат ECC у контроллера да и zfs ошибки не корректирует - тебя кто-то обманул
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от torvn77 (ok), 17-Дек-23, 11:55
	>> очень удобно когда ФС знает что и как прочиталось и может сама откорректировать ошибку > можешь взять результат ECC у контроллера да и zfs ошибки не корректирует > - тебя кто-то обманул Ты о разных версиях zraid забыл.   Ну и в любом случае, 1. выявление факта порчи хорошо само по себе.   2. подсчёт хешсуммы надёжнее проверки чётности
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 17-Дек-23, 13:43
	zfs не корректирует ошибки, она другую копию может дать но для этого надо диск в два раза больше и похорошему надо на разных дисках хранить и на разных компьютерах
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от torvn77 (ok), 17-Дек-23, 21:50
	> zfs не корректирует ошибки, она другую копию может дать но для этого > надо диск в два раза больше и похорошему надо на разных > дисках хранить и на разных компьютерах Может откоректировать через исключающее ИЛИ
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 18-Дек-23, 12:40
	Она может взять избыточную копию если она есть или у раида запросить если он есть пересобрать копию c учётом чойтности, контольная сумма для определения ошибки а не для корреции.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от torvn77 (ok), 18-Дек-23, 16:36
	> Она может взять избыточную копию если она есть или у раида запросить > если он есть пересобрать копию c учётом чойтности, контольная сумма для > определения ошибки а не для корреции. Контрольная сумма нужна чтобы понять что блок имеет повреждение, а потом чтобы понять что он восстановился правильно, а не так чтоб чётность восстановилась.   (в отличии от хешсум проверка чётности вообще может пропустить ошибку если повредились два бита)
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 18-Дек-23, 17:53
	> в отличии от хешсум проверка чётности вообще может пропустить ошибку если повредились два бита сколько можно восстановить зависит от алгоритма FEC и количества избыточной информации, сомневаюсь что кто-то код Хэминга сейчас использует - RS, BCH, LDPC и др. В nand есть отдельные области для хранения избыточной информации, какие алгоритмы используются зависит от производителя контроллеров, в sef есть и раиды свои и копии избыточные не только zfs умеет хранить да и контрольные суммы тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 19-Дек-23, 01:22
	> сколько можно восстановить зависит от алгоритма FEC и количества избыточной информации, > сомневаюсь что кто-то код Хэминга сейчас использует - RS, BCH, LDPC и др. А RAID1 какой - очень полезен на тот случай если это не прокатило, или девайс взял да и сдох совсем. В случае чексумм возможен продвинутый уровень - понять какая из копий при этом еще и правильная, и из нее починить вторую. Во всяком случае на btrfs оно вот так работает - и для флешатины почему-то сейчас очень модно выгружать наружу битые блоки не репортя IO error. И толку вам с их BCH или чего там - если оно вот так в результате? > В nand есть отдельные области для хранения избыточной информации, > какие алгоритмы используются зависит от производителя контроллеров, в sef есть и > раиды свои и копии избыточные не только zfs умеет хранить да > и контрольные суммы тоже. Врядли SEF сможет в управление девайсами того уровня... и да, снапшоты и проч - тоже полезные фичи, особенно на системном диске. Можно при факапе вместо реинстала системы полдня откатить все как было за 2 минуты и попробовать еще раз. Почти как на виртуалке - только на bare metal. Вон то не адресует этот аспект. А лепить это из этажерок типа LVM - оно получается хреновое, сложное, горбато работает и - менеджмент ужасен.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 19-Дек-23, 02:05
	> А RAID1 какой - очень полезен на тот случай если это не прокатило, или девайс взял да и сдох совсем. про код Хэмминга я имел ввиду не используют в nand - сейчас в ходу tlc qlc с огромным количество ошибок, в slc он может ещё был актуален >  Можно при факапе вместо реинстала системы полдня откатить все как было за 2 минуты и попробовать еще раз. что за мифические факапы - диск помрёт и никакие снапшоты не помогут. Я своё рабочее окружение могу в любой точке мира создать с нуля, главное чтобы инет был.
	Ответить | Правка | Наверх | Cообщить модератору

10. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
Сообщение от Аноним (10), 13-Дек-23, 00:35
>набор патчей для ядра Linux ... которые почему-то не в мэйнлайне.
Ответить | Правка | Наверх | Cообщить модератору

11. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
Сообщение от Аноним (11), 13-Дек-23, 00:36
не понял. А jffs2, которая работает поверх голых mtd-устройств? В чем новизна-то?
Ответить | Правка | Наверх | Cообщить модератору

	13. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 13-Дек-23, 00:43
	> А jffs2, которая работает поверх голых mtd-устройств? так и останется для голых mtd устройств > В чем новизна-то? очевидно SEF это не голое mtd устройство
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 13-Дек-23, 12:02
	> не понял. А jffs2, которая работает поверх голых mtd-устройств? В чем новизна-то? Ты наверное не видел как JFFS2 работает на больших устройствах. И сколько времени может занять монтирование файлухи крупнее пары гигз.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	92. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Kuromi (ok), 14-Дек-23, 17:03
	> не понял. А jffs2, которая работает поверх голых mtd-устройств? В чем новизна-то? Это не голое mtd, это скорее его эволюционное развитие с учетом опыта SSD. Хотят взять лучшее отовсюду.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

17. "Опубликована платформа SEF для программно управляемых Flash-..."	–9 +/–
Сообщение от Аноним (1), 13-Дек-23, 01:37
Локальные хранилища -- прошлый век. Нужна нативная интеграция с облаками без всяких посредников хоть в виде ссд и хдд.
Ответить | Правка | Наверх | Cообщить модератору

	19. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (19), 13-Дек-23, 04:03
	Нужна, но для этого нужны соответствующие скорости передачи данных и энергонезависимая оперативная память, а по-хорошему ещё и энергонезависимые ЦПУ. Но пока этого всего даже на горизонте не видно, так что локальный NAND-кэш ещё надолго с нами.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от ryoken (ok), 13-Дек-23, 07:53
	> Локальные хранилища -- прошлый век. Нужна нативная интеграция с облаками без всяких > посредников хоть в виде ссд и хдд. Вот завтра дядя на экскаваторе тяпнет кабель твоего прова и привет облакам. А послезавтра Вася-электрик не тот рубильник дёрнет.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	67. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (19), 13-Дек-23, 17:52
	Если кабель провайдера экскаватором тяпнуть, облачное хранилище никуда от этого не исчезнет. Ну посидишь без любимого сериала день, авось не одичаешь. На крайний случай в библиотеке вайфай есть, поработать хватит. А без электричества компьютер и вовсе бесполезен, что с дисками, что без.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 13-Дек-23, 22:11
	> Вот завтра дядя на экскаваторе тяпнет кабель твоего прова и привет облакам. > А послезавтра Вася-электрик не тот рубильник дёрнет. Тут вот какие-то добрые дяди на 2 дня суперстар вырубили. А у других соответственно вырубилась база налоговиков, обмен любезностями. Намекающий что - вот - можно на пару дней без интернета остаться на весь город, если добрые хакеры в гости на "коммутатор" сотовой сети зашли.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	33. "Опубликована платформа SEF для программно управляемых Flash-..."	+1 +/–
	Сообщение от Прыгающий Ленивец (?), 13-Дек-23, 09:22
	Нужна так смонтируй ядиск по WebDAV да пользуйся
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	50. "Опубликована платформа SEF для программно управляемых Flash-..."	+2 +/–
	Сообщение от glad_valakas (?), 13-Дек-23, 13:56
	тонко ! в то время как яндекс всеми силами стремится всех пересадить на свой фирменный клиент и удушить доступ по WebDAV.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (36), 13-Дек-23, 09:54
	Это все может работать в гибридном режиме. Первично конечно локальное хранилище. А отрицание его - крайняя мера.. т.е. если данные не нужны, то пожалуйста интегрировай хоть куда.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	37. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (8), 13-Дек-23, 10:15
	> Локальные хранилища -- прошлый век нет, но со временем локальная память будет энергонезависимая RAM без дурацких атавизмов типа zfs - можете отнести мои слова в банк!
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	38. "Опубликована платформа SEF для программно управляемых Flash-..."	+5 +/–
	Сообщение от Аноним (38), 13-Дек-23, 10:50
	Облако - это всего лишь локальное хранилище кого-то другого.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	39. "Опубликована платформа SEF для программно управляемых Flash-..."	+2 +/–
	Сообщение от Аноним (36), 13-Дек-23, 10:54
	Самое лучшее определение
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Опубликована платформа SEF для программно управляемых Flash-..."	+2 +/–
	Сообщение от Аноним (-), 13-Дек-23, 12:05
	> Локальные хранилища -- прошлый век. Нужна нативная интеграция с облаками > без всяких посредников хоть в виде ссд и хдд. Ну конечно, здорово же если чужой дядя все потер и аккаунт индейца забанил с аргументом что ему не нравится морда лица, профита с сервиса что-то маловато, или что там еще, а оспорить это - можно путем написания в спортлото.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	53. "Опубликована платформа SEF для программно управляемых Flash-..."	+3 +/–
	Сообщение от тов. майор (?), 13-Дек-23, 14:08
	>Нужна нативная интеграция с облаками без всяких посредников хоть в виде ссд и хдд. Одобряю! Всегда заботящийся о вас, тов. майор.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	72. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от glad_valakas (?), 13-Дек-23, 19:25
	> Одобряю! Всегда заботящийся о вас, тов. майор. и видеонаблюдение в туалетах ведется тоже для заботы о вашей безопастности.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Опубликована платформа SEF для программно управляемых Flash-..."	+1 +/–
	Сообщение от Kuromi (ok), 14-Дек-23, 17:07
	> Локальные хранилища -- прошлый век. Нужна нативная интеграция с облаками без всяких > посредников хоть в виде ссд и хдд. Да да да, как раз недавно на Ютубчике шитсторм был, на тему того что Гугль Драйв потерял кучу данных пользователей (корейцев в основном) и тут ВНЕЗАПНО оказалось что по User Agreement Google вообще ничего никому не гарантирует, а сохранность файлов и резервные копии это проблема исключительно клиента. ДАЖЕ на платных тарифах. Кто-то там потерял какие-то важные (для них) документы, вроде домашней бухгалтерии, им сказали "ну сорян" и закрыли тикет как solved. "Cloud is another man computer" внезапно.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	113. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Neon (??), 17-Дек-23, 00:25
	В век взаимных санкций и торговых войн облака плохая идея.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

30. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
Сообщение от Аноним (30), 13-Дек-23, 09:06
Такое было бы удобно для превращения отстойных SMR hdd дисков в обычные меньшего объёма или нормализации скорости их работы с использованием CoW подходов
Ответить | Правка | Наверх | Cообщить модератору

	41. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от 1 (??), 13-Дек-23, 11:10
	Ну такое удобно для построения СХД, где главное - это ПО, а не 2 ПО одна железка (одно ПО в диске). Не даром же все энтерпрайзные СХД требовали своей "тупой" прошивки дисков, чтоб те чего не удумали ...
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 13-Дек-23, 12:06
	> Такое было бы удобно для превращения отстойных SMR hdd дисков в обычные > меньшего объёма или нормализации скорости их работы с использованием CoW подходов ЧСХ в btrfs - zoned mode support завез - только подумайте - WD :))
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	94. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Kuromi (ok), 14-Дек-23, 17:12
	>> Такое было бы удобно для превращения отстойных SMR hdd дисков в обычные >> меньшего объёма или нормализации скорости их работы с использованием CoW подходов > ЧСХ в btrfs - zoned mode support завез - только подумайте - > WD :)) А это потому что WD увязли в SMR, воти  приходится теперь трепыхаться. Сигейт пошел по пути HAMR, а у WD не получается. Ждемс когда Сигейт начнет отгружать HAMR и посмотрим как они себя ведут и доедут ли до обычных пользователей. От SSD народ уже не отучишь, конечно, исход все равно любопытен.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (96), 14-Дек-23, 20:50
	> А это потому что WD увязли в SMR Эти слова подразумевают, что WD наращивает или будет наращивать ёмкость за счёт SMR, а Seagate - нет, а это не так. И WD сейчас из 24 ТБ CMR делает 28 ТБ SMR, и Seagate. В roadmap'е WD нет дальнейшего уплотнения SMR, там CMR на 30+ ТБ за счёт "ePMR 2" (ну и признаётся отставание по HAMR). https://www.anandtech.com/show/18908/western-digital-estimat...
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (96), 14-Дек-23, 20:57
	Точнее говоря, SMR у WD останется в самых ёмких дисках, а у Seagate в 2024 такие диски должны быть с HAMR и без SMR.
	Ответить | Правка | Наверх | Cообщить модератору

55. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
Сообщение от YetAnotherOnanym (ok), 13-Дек-23, 14:35
> вынести логику низкоуровневой работы с чипом Flash-памяти на сторону программного обеспечения и операционной системы Ой, ну спасибо! Раньше ОС прочла-записала и дальше свои задачи считает, а теперь 3-гигагерцовый 8-ядерник будет лично судьбой каждого байта заниматься, высчитывать для каждой операции записи, что в какой блок оптимальнее запихнуть, чтобы износ флэш-чипа уменьшить.
Ответить | Правка | Наверх | Cообщить модератору

	58. "Опубликована платформа SEF для программно управляемых Flash-..."	+1 +/–
	Сообщение от Аноним (56), 13-Дек-23, 14:50
	Раньше в телефонах/планшетах голую NAND-флешку ставили, ещё на той производительности тогдашных SoC, и тогда андроиды шустрее работали чем нынешные на всяких UFS
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Опубликована платформа SEF для программно управляемых Flash-..."	+1 +/–
	Сообщение от Аноним (19), 13-Дек-23, 17:55
	Это решение не для твоего локалхоста, а для программно определяемых систем хранения данных, хостов виртуальных машин и тому подобного. На локалхосте у тебя как был обычный NVMe, так и дальше будет.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	85. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от YetAnotherOnanym (ok), 14-Дек-23, 14:29
	В том виде, в каком это описано - это именно для локалхоста, который не несёт сколь-нибудь серьёзной нагрузки, когда можно позволить себе загрузить свой писслейк задачей управлять распределением данных по чипам. Когда нужна эффективность - такие задачи перекладываются на контроллер.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Kuromi (ok), 14-Дек-23, 17:15
	> Это решение не для твоего локалхоста, а для программно определяемых систем хранения > данных, хостов виртуальных машин и тому подобного. На локалхосте у тебя > как был обычный NVMe, так и дальше будет. Я пологаю что это не только энтерпрайз, но и общий поворот\шажок в развитии Flash. Вполне возможно что подобное со временем вытеснит "классику" с блочными устройствами  и черными ящиками. Когда - это другой вопрос, некоторые апологеты SSD предполагали что HDD уже годы как должны быть мертвы как класс.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

57. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
Сообщение от Аноним (56), 13-Дек-23, 14:46
Неужели наконец доделают поддержку NAND-памяти в mainline linux для старых allwinner планшетов?
Ответить | Правка | Наверх | Cообщить модератору

	123. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 17-Дек-23, 23:08
	> Неужели наконец доделают поддержку NAND-памяти в mainline linux для > старых allwinner планшетов? Да ее вроде доделали, но... 1) У HW randomizer затыкающего чувствительность хлипких MLC к повторяющимся паттернам там разный seed для boot и main area. Поэтому чтение/запись такой флешки - не очень скучный процесс. Физически данные записываются "шифроваными" (рандомизироваными) для устранения паттернов - и нет, данные записанные с другим seed корректно не читаются, конечно. 2) UBI ничего не знает про read disturbance, и в целом довольно маргинально готов к встрече с MLC и потому не рекомендуется... Так что попытаться завести - можно. Но как это будет работать - вопрос номер два. NAND начиная с MLC настолько канительный стал что совсем напрямую с ним связываться - вот - очень гиморно. В этом смысле кстати SPI-NAND умнее сделали, ECC встроенный в чип и им самим рюхается. Так попроще.
	Ответить | Правка | Наверх | Cообщить модератору

59. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
Сообщение от Аноним (59), 13-Дек-23, 15:30
> В обычных Flash для внешних систем накопитель представляет собой чёрный ящик, часть памяти в котором резервируется под служебные операции, ... В отличие от традиционных Flash-накопителей, распределением данных, изоляцией сбойных блоков и сборкой мусора в которых занимается прошивка контроллера Как дампануть эту прошивку флешки, SSD?
Ответить | Правка | Наверх | Cообщить модератору

	65. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (66), 13-Дек-23, 17:09
	> Как дампануть эту прошивку флешки, SSD? Пара самых очевидных способов... 1) JTAG. 2) BootROM. Конечно же простых и очевидных методов никто не даст. Но если вы пошаритесь по специфичным форумам - даже найдете примеры HOW TO, а то и пинауты JTAG, служебной сериальной консоли, команды, или что вы там хотели. Готовое решение мало кто даст, они денег стоят и продаются ремонтерам и датарекам.
	Ответить | Правка | Наверх | Cообщить модератору

81. "Опубликована платформа SEF для программно управляемых Flash-..."	+1 +/–
Сообщение от Аноним (1), 14-Дек-23, 00:50
Такое решение давно напрашивалось. Получается теперь можно убрать с накопителей всю лишнюю обвязку, а задачи управления всем массивом накопителей можно переложить, например, на отдельную плату расширения. Дешевле, надёжнее, гибче.
Ответить | Правка | Наверх | Cообщить модератору

	108. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Айнаниммм (?), 16-Дек-23, 15:10
	И полность несовместимо с огромным количеством устройств. А ещё производительность центрального процессора нужно увеличить, т.к. ему ещё стопка операций на выполнение прийдёт...
	Ответить | Правка | Наверх | Cообщить модератору

104. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
Сообщение от Аноним (104), 15-Дек-23, 13:57
Кто знает, в "флешках" и SD-картах есть встроенная балансировка износа?
Ответить | Правка | Наверх | Cообщить модератору

	121. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от Аноним (-), 17-Дек-23, 23:00
	> Кто знает, в "флешках" и SD-картах есть встроенная балансировка износа? А вот ктулху его знает - от причуд конкретной фирмвари зависит. Сорцы оной нам выдать - забыли. Поэтому там что угодно может быть. В зависимости от производителя, модели, версии фирмвари и чего там еще.
	Ответить | Правка | Наверх | Cообщить модератору

107. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
Сообщение от Айнаниммм (?), 16-Дек-23, 15:07
сперва win-модемы, потом win-принтеры, теперь win-диски...
Ответить | Правка | Наверх | Cообщить модератору

	112. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от torvn77 (ok), 16-Дек-23, 22:43
	> сперва win-модемы, потом win-принтеры, теперь win-диски... Ну в случае дисков это хорошо.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Опубликована платформа SEF для программно управляемых Flash-..."	+/–
	Сообщение от benu (ok), 21-Мрт-24, 14:51
	win-RAID пользуется успехом.
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

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

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