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

Опубликована платформа SEF для программно управляемых Flash-накопителей, opennews (??), 12-Дек-23, (0) [смотреть все] Ничего не понятно, но очень интересно , Аноним (1), 23:41 , 12-Дек-23, (1) +4 // Все прекрасно понятно накопитель сознательно превращается в максимально тупое у, Аноним (3), 00:15 , 13-Дек-23, (3) +9 Идея в том чтобы вытащить всю ту логику что сейчас делает контроллер, вроде выра, Kuromi (ok), 00:18 , 13-Дек-23, (5) +2 // Куча флех и ссдшек помирает из-за скоропостижной кончины контроллера Отсюда вопр, Аноним (-), 00:42 , 13-Дек-23, (12) +1   // Хороший вопрос Либо на хосте либо на самом устройстве либо отдельно выделенная , Kuromi (ok), 02:33 , 13-Дек-23, (18)   Да, под метадатой я имел в виду данные о износе, информацию о разделении на вирт, Анонимусс (?), 13:57 , 13-Дек-23, (51)   Метаданные внезапно хранятся всё в том же флеше , Tron is Whistling (?), 09:49 , 13-Дек-23, (34)   В обычных SSD - да, да и сама прошивка чаще всего - тоже Поэтому слеты таблицы , Kuromi (ok), 15:59 , 14-Дек-23, (86)   А тут не будет контроллера, значит помирать контроллер не может, Аноним (56), 14:44 , 13-Дек-23, (56)   Контроллер какой-то все равно будет, ты же не пишешь в ячейки напрямую, просто о, Kuromi (ok), 16:03 , 14-Дек-23, (87)   Контроллер там живее всех живых, если умирает контроллер - устройство вообще при, Аноним (61), 16:30 , 13-Дек-23, (61)   Скрыто модератором, Аноним (-), 16:57 , 13-Дек-23, (63) +1   Скрыто модератором, Аноним (61), 19:22 , 13-Дек-23, (71)   Скрыто модератором, Аноним (-), 21:25 , 13-Дек-23, (75)   Скрыто модератором, Аноним (61), 23:11 , 13-Дек-23, (80)   Скрыто модератором, Аноним (-), 01:08 , 15-Дек-23, (100)   Скрыто модератором, Аноним (-), 21:26 , 13-Дек-23, (76) +1   Если в SSD встроен кэш статический динамический как в у Самсунг или есть SLC, Kuromi (ok), 16:20 , 14-Дек-23, (88)   редко встречается я ниразу не видел чтобы флеш память накрылась внезапно- тол, Вася (??), 20:04 , 13-Дек-23, (73)   Я именно об этом и написал Ну согласен на SSD стараются не допускать, чтобы ф, Аноним (84), 13:44 , 14-Дек-23, (84)   Это жеж гораздо более лёгкая нагрузка, чем типичная для системного диска , Аноним (96), 20:09 , 14-Дек-23, (96)   Не знаю как современные контроллеры, а раньше контроллер убивался достаточно про, torvn77 (ok), 22:20 , 16-Дек-23, (110)   Будто и у hdd он сдохнуть не может Единственный плюс в том что hdd в теории до, torvn77 (ok), 22:11 , 16-Дек-23, (109)   Блин хоть бы раз увидеть такое живъем Обычно либо не определяется вообще, либо , Аноним (83), 11:57 , 14-Дек-23, (83)   Было было У меня так пара карт памяти безмолвно перешли в режим read-only, прич, Kuromi (ok), 16:23 , 14-Дек-23, (89)   Так там же FTL выложен Так можно косплеить хоть блочный девайс, или что там удо, Аноним (-), 11:57 , 13-Дек-23, (43) +1 Учитывая что для возни с банками твердотельника выделен контроллер отдельный мн, Бывалый смузихлёб (?), 12:50 , 13-Дек-23, (49) +1 // Вот ща бы при многоядерниках даже в телефоне проц только и экономить Если даже , Аноним (-), 17:00 , 13-Дек-23, (64) +1 Если на обслуживание 1 накопителя уйдёт 2 ядра, то на 2 накопителя уйдёт уже 4 я, Бывалый смузихлёб (?), 18:27 , 13-Дек-23, (69) –1 Ну так там и проц поди будет минимум ядер на 16 Вон там амд с интелем соревную, Аноним (-), 21:39 , 13-Дек-23, (77) +1 Там запретили асинхронный TRIM т е команды на TRIM идут вместе обычными на чте, Kuromi (ok), 17:00 , 14-Дек-23, (91) Скрыто модератором, Аноним (-), 22:45 , 17-Дек-23, (119) Скрыто модератором, Kuromi (ok), 23:05 , 17-Дек-23, (122) Скрыто модератором, Аноним (-), 00:28 , 18-Дек-23, (124) Скрыто модератором, Kuromi (ok), 00:36 , 18-Дек-23, (125) Скрыто модератором, Аноним (96), 04:12 , 18-Дек-23, (126) А вы уверены что они выкинут вообще все, включая процы контроллера Прошлый раз , Kuromi (ok), 16:28 , 14-Дек-23, (90) Ну хоть одна здравая идея Или вендоры настолько косячат, что силы молчать нет П, Аноним (74), 21:16 , 13-Дек-23, (74) всё понятно где купить , нокия (?), 23:51 , 12-Дек-23, (2) // Обращайтесь в KIOXIA, они выпускаютhttps www prnewswire com news-releases soft, Аноним (3), 00:18 , 13-Дек-23, (4) +1 Ты хотел сказать скачать и собрать Насколько я понал - то ты подключаешь кучу , Аноним (-), 00:26 , 13-Дек-23, (7) // от ворот поворот, т к контроллер там старой закалки, Аноним (35), 09:52 , 13-Дек-23, (35) +1 Нет, нужны специальные накопители с поддержкой этой фичи В существующих накопит, Аноним (3), 16:24 , 13-Дек-23, (60) Жаль А ведь технология подавала надежды Но с таким инструментарием оно способн, Шарп (ok), 00:24 , 13-Дек-23, (6) –13 // Зато каких эпичных Просто представь лицо юзера, когда вся порнуха исчезнет с ег, Аноним (-), 00:29 , 13-Дек-23, (9) +1 // Это когда своим трудом не могут заработать, поэтому учат студентов , nox. (?), 07:07 , 13-Дек-23, (25) –2 // учить студентов - тоже работа А так это же со времён СССР - Не можешь работ, 1 (??), 11:07 , 13-Дек-23, (40) В ядре Линукса код используется практически, а академический так и остаётся в ак, Аноним (52), 14:04 , 13-Дек-23, (52) Ну ты можешь на шарпе написать фирмварь накопителя и системный софт Посмотрим ч, Аноним (-), 11:58 , 13-Дек-23, (44) который отправляет zfs и прочие ненужные усложнённые фс на свалку истории, Аноним (8), 00:27 , 13-Дек-23, (8) –3 // Глядя на то как btrfs запилил поддержку Zoned - на минуточку, это почти ответка , Аноним (-), 12:01 , 13-Дек-23, (45) // в btrfs cow само по себе прекрасно ложится на флеши - запись всегда в новую обла, Аноним (8), 14:14 , 13-Дек-23, (54) // В случае btrfs чексуммы дают дополнительные возможности Скажем, копий может быт, Аноним (66), 17:09 , 13-Дек-23, (66) а смысл держать 4 копии в одном месте - есть распределённые фс, а так у тебя эле, Аноним (8), 18:40 , 13-Дек-23, (70) Ну например если есть 4 накопителя, можно метаданные для надежности как RAID1C, Аноним (-), 21:57 , 13-Дек-23, (78) не понимаю в чём сложность что диск стал больше - воткнули новый диск, через cli, Аноним (8), 08:14 , 14-Дек-23, (82) А данные с старого диска на новый - телепортируются А оба диска на пару как 1 с, Аноним (-), 22:55 , 17-Дек-23, (120) во первых зачем телепортировать - устройства логические, ты LBA видишь снаружи, , Аноним (8), 23:44 , 18-Дек-23, (130) Есть минимум 3 причины закопировать или переместить данные на другой накопитель , Аноним (-), 01:14 , 19-Дек-23, (131) последний абзац новости намекает что всё это есть, мне лень погружаться, Аноним (8), 01:37 , 19-Дек-23, (133) На голые флеши его класть нельзя, flash translation layer для выравнивания износ, Аноним (96), 22:08 , 14-Дек-23, (99) дело не в cow а в том что монстрофс с cow хранят снапшоты - для пользователя каж, Аноним (8), 10:21 , 15-Дек-23, (101) Нет, это дело ещё более опциональное, чем дублирование метаданных, а коровья сущ, Аноним (96), 11:52 , 15-Дек-23, (102) только в лучшую сторону, например специальная фс для nand ubifs - спроектирована, Аноним (8), 12:48 , 15-Дек-23, (103) Я с обобщениями ещё вот где напортачил Write amplification на практике могут оп, Аноним (96), 22:10 , 15-Дек-23, (105) тоже мне бином ньютона - что мешает считать обращения к логическим блокам а не т, Аноним (8), 11:38 , 16-Дек-23, (106) Не согласен, очень удобно когда ФС знает что и как прочиталось и может сама отко, torvn77 (ok), 22:33 , 16-Дек-23, (111) можешь взять результат ECC у контроллера да и zfs ошибки не корректирует - тебя , Аноним (8), 11:31 , 17-Дек-23, (114) Ты о разных версиях zraid забыл Ну и в любом случае, 1 выявление факта порчи , torvn77 (ok), 11:55 , 17-Дек-23, (115) zfs не корректирует ошибки, она другую копию может дать но для этого надо диск в, Аноним (8), 13:43 , 17-Дек-23, (116) Может откоректировать через исключающее ИЛИ, torvn77 (ok), 21:50 , 17-Дек-23, (117) Она может взять избыточную копию если она есть или у раида запросить если он ест, Аноним (8), 12:40 , 18-Дек-23, (127) Контрольная сумма нужна чтобы понять что блок имеет повреждение, а потом чтобы п, torvn77 (ok), 16:36 , 18-Дек-23, (128) сколько можно восстановить зависит от алгоритма FEC и количества избыточной инфо, Аноним (8), 17:53 , 18-Дек-23, (129) А RAID1 какой - очень полезен на тот случай если это не прокатило, или девайс вз, Аноним (-), 01:22 , 19-Дек-23, (132) про код Хэмминга я имел ввиду не используют в nand - сейчас в ходу tlc qlc с огр, Аноним (8), 02:05 , 19-Дек-23, (134) которые почему-то не в мэйнлайне , Аноним (10), 00:35 , 13-Дек-23, (10) не понял А jffs2, которая работает поверх голых mtd-устройств В чем новизна-то, Аноним (11), 00:36 , 13-Дек-23, (11) // так и останется для голых mtd устройствочевидно SEF это не голое mtd устройство, Аноним (8), 00:43 , 13-Дек-23, (13) Ты наверное не видел как JFFS2 работает на больших устройствах И сколько времен, Аноним (-), 12:02 , 13-Дек-23, (46) Это не голое mtd, это скорее его эволюционное развитие с учетом опыта SSD Хотят, Kuromi (ok), 17:03 , 14-Дек-23, (92) Локальные хранилища -- прошлый век Нужна нативная интеграция с облаками без вся, Аноним (1), 01:37 , 13-Дек-23, (17) –9 // Нужна, но для этого нужны соответствующие скорости передачи данных и энергонезав, Аноним (19), 04:03 , 13-Дек-23, (19) Вот завтра дядя на экскаваторе тяпнет кабель твоего прова и привет облакам А по, ryoken (ok), 07:53 , 13-Дек-23, (28) // Если кабель провайдера экскаватором тяпнуть, облачное хранилище никуда от этого , Аноним (19), 17:52 , 13-Дек-23, (67) Тут вот какие-то добрые дяди на 2 дня суперстар вырубили А у других соответстве, Аноним (-), 22:11 , 13-Дек-23, (79) Нужна так смонтируй ядиск по WebDAV да пользуйся, Прыгающий Ленивец (?), 09:22 , 13-Дек-23, (33) +1 // тонко в то время как яндекс всеми силами стремится всех пересадить на свойфирме, glad_valakas (?), 13:56 , 13-Дек-23, (50) +2 Это все может работать в гибридном режиме Первично конечно локальное хранилище , Аноним (36), 09:54 , 13-Дек-23, (36) нет, но со временем локальная память будет энергонезависимая RAM без дурацких ат, Аноним (8), 10:15 , 13-Дек-23, (37) Облако - это всего лишь локальное хранилище кого-то другого , Аноним (38), 10:50 , 13-Дек-23, (38) +5 // Самое лучшее определение , Аноним (36), 10:54 , 13-Дек-23, (39) +2 Ну конечно, здорово же если чужой дядя все потер и аккаунт индейца забанил с арг, Аноним (-), 12:05 , 13-Дек-23, (47) +2 Одобряю Всегда заботящийся о вас, тов майор , тов. майор (?), 14:08 , 13-Дек-23, (53) +3 // и видеонаблюдение в туалетах ведется тоже для заботы о вашей безопастности , glad_valakas (?), 19:25 , 13-Дек-23, (72) Да да да, как раз недавно на Ютубчике шитсторм был, на тему того что Гугль Драйв, Kuromi (ok), 17:07 , 14-Дек-23, (93) +1 В век взаимных санкций и торговых войн облака плохая идея , Neon (??), 00:25 , 17-Дек-23, (113) Такое было бы удобно для превращения отстойных SMR hdd дисков в обычные меньшего, Аноним (30), 09:06 , 13-Дек-23, (30) // Ну такое удобно для построения СХД, где главное - это ПО, а не 2 ПО одна железка, 1 (??), 11:10 , 13-Дек-23, (41) ЧСХ в btrfs - zoned mode support завез - только подумайте - WD , Аноним (-), 12:06 , 13-Дек-23, (48) // А это потому что WD увязли в SMR, воти приходится теперь трепыхаться Сигейт по, Kuromi (ok), 17:12 , 14-Дек-23, (94) // Эти слова подразумевают, что WD наращивает или будет наращивать ёмкость за счёт , Аноним (96), 20:50 , 14-Дек-23, (97) Точнее говоря, SMR у WD останется в самых ёмких дисках, а у Seagate в 2024 такие, Аноним (96), 20:57 , 14-Дек-23, (98) Ой, ну спасибо Раньше ОС прочла-записала и дальше свои задачи считает, а теперь, YetAnotherOnanym (ok), 14:35 , 13-Дек-23, (55) // Раньше в телефонах планшетах голую NAND-флешку ставили, ещё на той производитель, Аноним (56), 14:50 , 13-Дек-23, (58) +1 Это решение не для твоего локалхоста, а для программно определяемых систем хране, Аноним (19), 17:55 , 13-Дек-23, (68) +1 // В том виде, в каком это описано - это именно для локалхоста, который не несёт ск, YetAnotherOnanym (ok), 14:29 , 14-Дек-23, (85) Я пологаю что это не только энтерпрайз, но и общий поворот шажок в развитии Flas, Kuromi (ok), 17:15 , 14-Дек-23, (95) Неужели наконец доделают поддержку NAND-памяти в mainline linux для старых allwi, Аноним (56), 14:46 , 13-Дек-23, (57) // Да ее вроде доделали, но 1 У HW randomizer затыкающего чувствительность хлипк, Аноним (-), 23:08 , 17-Дек-23, (123) Как дампануть эту прошивку флешки, SSD , Аноним (59), 15:30 , 13-Дек-23, (59) // Пара самых очевидных способов 1 JTAG 2 BootROM Конечно же простых и очевидн, Аноним (66), 17:09 , 13-Дек-23, (65) Такое решение давно напрашивалось Получается теперь можно убрать с накопителей , Аноним (1), 00:50 , 14-Дек-23, (81) +1 // И полность несовместимо с огромным количеством устройств А ещё производительнос, Айнаниммм (?), 15:10 , 16-Дек-23, (108) Кто знает, в флешках и SD-картах есть встроенная балансировка износа , Аноним (104), 13:57 , 15-Дек-23, (104) // А вот ктулху его знает - от причуд конкретной фирмвари зависит Сорцы оной нам в, Аноним (-), 23:00 , 17-Дек-23, (121) сперва win-модемы, потом win-принтеры, теперь win-диски , Айнаниммм (?), 15:07 , 16-Дек-23, (107) // Ну в случае дисков это хорошо , torvn77 (ok), 22:43 , 16-Дек-23, (112) win-RAID пользуется успехом , benu (ok), 14:51 , 21-Мрт-24, (135) 1,2,6,8,10,11,17,30,55,57,59,81,104,107

Сообщения

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

	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ообщить модератору

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

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