Стирать можно и по очереди -- просто надо знать, какие сектора подлежат, и чтобы скорости хватало.
Я считаю, что всё должно быть как можно проще -- так все варианты проследить гораздо проще.
Более 2 копий всего иметь смысла не имеет -- одновременно гикнуться они смогут с квадратом вероятности, которая и так небольшая. Куб -- уже некрасиво и параноидально. Хотя 4 -- самое оно, если уж начальство совсем хочет перезастраховаться.
И писать бы данные неодновременно все 2-3-4 -- если по питанию помехи, то все N запишутся криво, но разносить во времени очень неудобно.
А если молния ударит или ЯВ -- то и 10 копий не спасут
Плохо, что сектора все кратны степени 2 и нельзя дописывать свои CRC, чтоб быстро определять, какое из данных сломалось. А если в другой сектор по 4 байта -- это неудобно, дубляж опять же, потом и на этот сектор надо CRC заводить в 3ю степень... Только если полсектора на данные, а остальное на проверку -- дублять так дублять !
Я вообще давно сторонник прятать всю эту отказоустойчивость в микросхему флэши -- ей лучше видно, что за ошибки, можно ли их исправить, стоит ли далее юзать данный № сектора или спрятать его в корзину навечно или до следующего форматирования... Хотя только явно ненормальный либераст мог родить в мир эти NANDы с огромадными единицами обработки, где принципиально ошибки допустимы, как класс, и надо их терпеть на верхнем уровне, пытаться лечить...
Интерфейс наружу мог бы быть простейшим -- ПО просит у кристалла выделить определённый № логического сектора (чисто отформатированного), записать его, прочитать его, ну и вернуть в "пул" свободных. Если микросхема что-то из этого не смогла, пусть вернёт ошибку. Да, и размер сектора можно запросить на старте, но 512 байт желательно по дефолту -- с громадными "от демократов" работать неудобно никому и никогда
Из такого набора операций можно легко устроить идеальную работу ОС, которая bad-ами не занимается вообще -- только плачется иногда юзеру, что какой-то вот файл битый при чтении, считанное содержимое в таком-то месте точно испорчено, а при записи -- пусть железо напряжётся и таки найдёт нормальный сектор, если в какой-то записать не вышло, перенамаппит его.
Нужно записать нечто -- смотрит по своим таблицам №№ незанятых секторов, запрашивает их у железа, пишет туда, а если уже файл не нужен -- возвращает обратно в пул его сектора. Тамошние данные уже потеряны навечно на 100 % (сектора вернутся "наружу" только при следующем запросе выделения поформатированными через цикл равномерной обработки всего свободного пула-"фифошки").
Внутренними перекодированиями №№ секторов в годные и таблицей негодных занимается железо -- это не очень трудно, только нужна память внутри чуть круче NAND для этих вещей, чтобы не сбоила "в теории" и писалась с произвольным доступом -- её немного надо, думаю, если NAND-ячейки сделать в 2 раза больше, то они сбиваться перестанут. Или пусть двоит, троит, четверит свою сбойную -- верхнему уровню это неинтересно.
А остальная хоть NAND, хоть что угодно из табакерки -- нас сверху интересует надёжный и простой интерфейс, а не реализация.
Форматированием тоже пусть железо занимается -- у него должна быть очередь из готовых к выдаче небитых секторов, голову списка нужно постоянно форматировать. Микроконтроллеры обязательно ставятся к каждой микросхеме флэши -- пусть этот "мозг" будет сразу встроен !
Из таких микросхем было бы очень удобно "набивать" устройства что с дубляжом, что просто карманные флэшки -- для дубляжа нужно просто параллельно работать с несколькими микросхемами, посылая им идентичные запросы, чтобы на всех сразу получалась одинаковая ФС. А с флэшками -- получится постоянно уменьшающийся диск, и когда юзеру надоест периодическая пропажа файлов или недостаточный объём, пусть купит новый девайс, но чтоб без внезапной пропажи сразу всего, как часто случается.
Ну то есть главный смысл этого потока: придумал кто-то гемор -- пусть лично его и мучает, а не перекладывает на другую голову, пока ещё белую и пушистую
Кстати, зачем столько дубляжа при ответах ?
Я лично стараюсь сильно цитировать в самом крайнем случае.
USB MTP протокол, Можно ли использовать не для медиа-данных
Sep 19 2014, 20:47
