Ищу надёжную FTL или файловую систему, С журналом и wear leveling Опции

[mvb]

Здравствуйте.
Пишу проект на ColdFire V2. Подскажите, кто знает, где достать реализацию файловой системы или хотя бы FTL с журналированием и возможно с ECC? Свежая версия uC/FS например выглядит очень соблазнительно, но недоступно (вот кстати, сколько она может стоить для гражданского применения? Может у кого-нибудь есть исходники? :-) ).
Это нужно для того, чтобы на NAND организовать файловую систему, устойчивую к сбоям и нерабочим битам.

Спасибо.

[vshemm]

Есть YAFFS, которая позиционируется в том числе как замена jffs2. Там есть все что надо, и даже больше.
К тому же, она не завязана на конкретную ОС и написана на чистом С, т.е. с портированием проблем минимум.
YAFFS немолодая (в хорошем смысле) и проверенная. Если не ошибаюсь, оверхед по памяти там 2 байта на
страницу, что при 512B страницах дает 4KB RAM на каждый 1MB Flash, что очень неплохо при имеющихся фичах.

С другой стороны, задача больше похожа на сохранение environment variables (как в том же uboot и пр.
загрузчиках). Поэтому использование ФС может быть оверинжинирингом и стоит рассмотреть вариант со своим
велосипедом. Если количество переменных ограничено, как и длина их имен и данных, то реализация power-safe
сохранения довольно тривиальна. Правда, по сравнению с NVRAM тут понадобится дополнительный слой, связанный
со структурой NAND (страницы, блоки, spare, ECC и пр.), но это не так сложно и едва ли займет больше времени,
чем изучение той же uC/FS.

[AlexandrY]

Есть YAFFS, которая позиционируется в том числе как замена jffs2. Там есть все что надо,....
оверхед по памяти там 2 байта на страницу, что при 512B страницах дает 4KB RAM на каждый 1MB Flash,

Сейчас актуальна YFFS2. Но расчеты по памяти для нее не очень верны.
Там сразу около 12 Кб отхватывается под временные буфера и еще около 20 Кб идет на кэш.
Да и на SPI интерфейсе эта система будет тормозить неадекватно.

И DataFlash не является NAND. В DataFlash данные в блоке можно дописывать, и блок выдерживает 100000 стираний, а в NAND блоки нельзя дописывать и они выдерживают без появления ошибок только 1000 стираний.
И потому файловые ситемы на DataFlash и NAND сильно отличаются.
Что хорошо для NAND, то на SPI DataFlash будет жутко тормозить.

Недавно тестировал Keil FS на DataFlash. Тоже реализовывал сохранение статистики пусков агрегата. На 50 тыс записей файла размером пару десятков байт приходилось где-то 200 стираний сектора. При такой интенсивности стираний не нужно даже выравнивание износа и ECC
Вполне надежная FS.

[vshemm]

Сейчас актуальна YFFS2. Но расчеты по памяти для нее не очень верны.
Там сразу около 12 Кб отхватывается под временные буфера и еще около 20 Кб идет на кэш.

Я специально не указывал версию, т.к. формат JFFS1 может подойти в данном случае больше.
Расчеты вполне могут быть неточны - писал по памяти. Давайте подсчитаем для раздела <8MiB,
page size 512B, 100 файлов по 8KiB, кеши отключены (как описано здесь):
3608 + 100 * 124 + 100 * 32 = 19208, т.е. примерно ~20KB. Нормально это или нет - решать точно не нам.

И DataFlash не является NAND. В DataFlash данные в блоке можно дописывать, и блок выдерживает 100000 стираний, а в NAND блоки нельзя дописывать и они выдерживают без появления ошибок только 1000 стираний.
И потому файловые ситемы на DataFlash и NAND сильно отличаются.
Что хорошо для NAND, то на SPI DataFlash будет жутко тормозить.

Да вот как раз внутри DataFlash скорее всего стоит NAND:
1. 100000 циклов - это типичное значение для SLC NAND, а для NOR оно от 100000 - бесполезная в данном случае инфа.
2. Размер страницы как у NAND - 264, 528, 1056... - это page + spare.
3. Время стирания страницы - десятки мс - как у NAND.
4. Самое главное, что дописывание в страницу происходит по такому же принципу, что и у NAND: страница читается
во внутренний SRAM буфер, модифицируется, стирается старая страница во flash array, буфер записывается во flash
array. Т.е. часть работы делается внутренней логикой DataFlash, а снаружи кажется, что дописывание есть. Более
того, такое поведение требует, чтобы после каждых 10000 суммарных циклов такого дописывания рефрешился весь блок
(сектор), причем вручную - поэтому на "NOR поведение" рассчитывать вообще нельзя.

По большому счету, совсем неважно, на какой технологии построен flash array, главное что по поведению и
временным характеристикам это NAND (хоть и на стероидах, с внутренними буферами и доп командами). А, значит,
ФС для нанда должна нормально лечь на DataFlash. Конечно, незаточенная под DataFlash ФС не будет использовать
некоторые ее фичи (вроде прозрачного дописывания), однако основной оверхед может возникнуть только из-за копирования
данных по SPI вместо локального SRAM. Но, во-первых, модификация так и так будет происходить десятки мс из-за стирания
страницы, и лишний прогон 512 байт по SPI с частотой в десятки МГц особо производительность не уронит. А во-вторых,
YAFFS пишет только в предварительно стертые блоки, и данная атмелевская фича вообще не к месту.
Так что тормозить там нечему.

Вообще, такая тема уже поднималась, и все свелось к написанию своего велосипеда.

[_Артём_]

4. Самое главное, что дописывание в страницу происходит по такому же принципу, что и у NAND: страница читается
во внутренний SRAM буфер, модифицируется, стирается старая страница во flash array, буфер записывается во flash
array. Т.е. часть работы делается внутренней логикой DataFlash, а снаружи кажется, что дописывание есть.

Вы считаете нас обманывают?

7.3 Buffer to Main Memory Page Program without Built-in Erase

Page Programming Time (512/528 bytes) 3 6 3 6 ms

Page Erase and Programming Time 17 40 ms

Более
того, такое поведение требует, чтобы после каждых 10000 суммарных циклов такого дописывания рефрешился весь блок
(сектор), причем вручную - поэтому на "NOR поведение" рассчитывать вообще нельзя.

Откуда вы это взяли, что ещё и сектора надо стирать? Ссылку не дадите?