Надёжность NAND flash Опции

[Серокой]

прошу поделиться опытом.
Какова надёжность этого типа флеши (Samsung), требуется ли всегда читать бит правильности записи (чтения)?
И ещё мне остался совсем непонятен механизм замещения "битых" ячеек и включения ECC, в PDF расплывчато очень написано об этом.

[bmf]

c YAFFS работал
скажу про недостатки:
она не доделана (по тексту много замечаний) и больше не развивается (замещена пользу YAFFS2)
сразу расчитайте сколько надо RAM - для 128M NAND при кластере в 8KB - 128K, а в оригинале кажется для 2K нужно - 512K это минимум
Время запуска (ускоренная вычитка всех областей) для 128M - около 4sec
Непредсказуемые задержки в процессе выполнения (при накоплении данных в gabrage collection происходит их длительная очистка и перемещение)
для YAFFS2 структуры в памяти и требовательность к ресурсам еще больше
соответствнно для 512M NAND - все в 4 раза больше и дольше

единственное преимущество это нечувствительность к пропаданию питания

как по мне - она (что YAFFS, что YAFFS2) только для ресурсоемких систем, а по времени старта вообще сомнительна для embedded
Принцип работы - просто загрузить всю информацию о всех секторах и блоках в RAM и работать с ней, поэтому и такая ресурсоемкость и монстровитость.

[si21]

c YAFFS работал
скажу про недостатки:
она не доделана (по тексту много замечаний)  и больше не развивается (замещена пользу YAFFS2)
сразу расчитайте сколько надо RAM - для 128M NAND при кластере в  8KB - 128K, а в оригинале кажется для 2K нужно - 512K это минимум
Время запуска (ускоренная вычитка всех областей) для 128M - около 4sec
Непредсказуемые задержки в процессе выполнения (при накоплении данных в gabrage collection происходит их длительная очистка и перемещение)
для YAFFS2 структуры в памяти и требовательность к ресурсам еще больше
соответствнно для 512M NAND - все в 4 раза больше и дольше

единственное преимущество это нечувствительность к пропаданию питания

как по мне - она (что YAFFS, что YAFFS2) только для ресурсоемких систем, а по времени старта вообще сомнительна для embedded
Принцип работы - просто загрузить всю информацию о всех секторах и блоках в RAM и работать с ней, поэтому и такая ресурсоемкость и монстровитость.

С YAFFS2 (direct-mode, ARM CPU 90 Mhz) работаю и сейчас (раньше использовал портированную jffs - это небо и земля) и не совсем с Вами согласен.
1. Расход памяти (RAM) - зависит от конфигурирования (исходных параметров).
2. Gabrage collection - медленноват для NOR-flash, для NAND - очистка сектора (страницы) достаточно быстра (~ 2 ms) и тормозов практически нет
3. перемещение - в этом же суть ФС для флеш-памяти! Благодаря этому, сохраняется ресурс секторов на запись - нет их быстрого "убивания" (идет равномерное использование)!
4. Для обеспечения быстродействия - разумный компромис между RAM и Flash диском (используя все ту же YAFFS2).
5. Приблизительно - у меня в embedde-system - 3 раздела/диска (1 RAM, и 2 - на разных чипах - flash) темп поступления инфо - не менее 500-800 байт в 20-100 мс, все прекрасно (размер конечного файла - не менее 6-8 МБ + 30-40 статичных БД/ИФ файлов, из к-рых читается инфа)
6. Небольшую чистку исх. файлов YAFFS2 можно сделать - с точки зрения оптимизации.
Нормальный расход флеш (мой опыт): максим. использование объема - не более 60-70% (т.е., если, например, файлы совокупно будут использовать до 1 МБ, желательна флеш объемом не менее 1.6 МБ)

P.S. 1. Для NAND - приведено время очистки блока, а не страницы. Например, если размер страницы 2К, то размер блока м.б. 128К - т.е. 64 страницы, и время очистки блока - порядка 2 миллисекунд
2. YAFFS работает с NAND со страницами в 512 байт (+ 16), YAFFS2 - с NAND со страницами в 2К

[bmf]

Расход памяти (RAM) - зависит от конфигурирования (исходных параметров).

Особо не наконфигурируешь - на каждый сектор NADN надо как минимум 30 байт (точно не помню) RAM для хранения служебной информации.
Проще сказать так, если у вас OS типа Linux (и соответственно камень), то и эта файловая система для вас.
Для себя я выход нашел в следующем. Информация всегда пишется по кольцу и cтарая просто замещается новой. Логическая целостность обеспечивается link, прописанными в spare. При таком допущении требования к дополнительной памяти, сложности и объема кода, быстродействие всей системы получается более чем на порядок! Время старта - доли секунды. И все эти навороты полноценной файловой системы мне не к чему, т.к. задача архивирования актуальной информации решена, при полном использовании специфики NAND (одноктартное программирование, исправление однобитовых ошибок, учет битых блоков, стирание целым блоком).

[si21]

Особо не наконфигурируешь - на каждый сектор NADN надо как минимум 30 байт (точно не помню)  RAM для хранения служебной информации.
Проще сказать так, если у вас OS типа Linux (и соответственно камень), то и эта файловая система для вас.
Для себя я выход нашел в следующем. Информация всегда пишется по кольцу и cтарая просто замещается новой. Логическая целостность обеспечивается link, прописанными  в spare. При таком допущении требования к дополнительной памяти,  сложности и объема кода, быстродействие всей системы получается более чем на порядок!  Время старта - доли секунды. И все эти навороты полноценной файловой системы мне не к чему, т.к. задача архивирования актуальной информации решена, при полном использовании специфики NAND (одноктартное программирование, исправление однобитовых ошибок, учет битых блоков, стирание целым блоком).

Да нет, как раз Linux и не пользую - слишком много гробится времени в переключателе задач/обработке пр-ий и относительно много RAM жрет. Здесь меня пока выручает uCOS (минимальные накладные расходы и время отклика). В YAFFS1/2 как раз и нет "наворотов полноценной файловой системы" - т.к. собственно сам интерфейс файловой системы (для direct-mode) реализован буквально в одном примитивном файле с набором вызовов к ядру ФС, но тем не менее, реализовано все, что требуется - например, я работаю с полнофункциональной СУБД собственной разработки ("минималистская" реализация) и не испытываю никаких ограничений. Но, естественно, это мой опыт и мое мнение