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

Спасибо.

Пробовал jffs2 - не понравилось. Нужны специальные утилиты для форматирования и начальной записи. работает очень медленно. Особенно при под-монтировании.

Там, где писать на диск очень часто не требуется, остановился на ext3fs.

Спасибо, но у меня маленькая RTOS и ОЗУ 64 КБайт, Линукс не подходит :-(

Объем ОЗУ меньше размера блока NAND. Посмотрите SMIL - древность, конечно, зато как раз для мелких контроллеров предназначалось.

 SmilS10E.pdf ( 1.1 мегабайт ) Кол-во скачиваний: 798

 SmilH10E.pdf ( 355.28 килобайт ) Кол-во скачиваний: 347

ОЗУ это критично. С 64 Кб даже FAT на SD карте будет тормозить , так как нужен приличный кэш при интенсивной работе с файлами.
Нереально с таким ОЗУ иметь хорошую файловую систему на NAND.

Планируется использовать DataFlash от Atmel (правда уже больше не Атмел) -- в ней стирание по секторам 512 байт. Интенсивной работы с файлами не предполагается, т.ч. скорость не важна.
На самом деле файловую систему предполагается использовать для реализации надёжного энергоназвисимого хранилища некоторого набора разнородных записей, очень редко изменяемых. Перечень записей может менятся, сами записи могут менять свой размер, адресовать отдельную запись нужно указывая некоторую строку-имя этой записи, т.ч. ФС подходит как нельзя лучше. В первую очередь нужна журналируемость, экономия ресурса флеш-памяти не обязательна, т.к. записи меняются крайне редко.

Спасибо за pdf -- изучу.

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

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

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

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

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

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



Да вот как раз внутри 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 пишет только в предварительно стертые блоки, и данная атмелевская фича вообще не к месту.
Так что тормозить там нечему.

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

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










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

А кто говорил, что надо стирать сектор? Стирать не обязательно, а вот страницы в некоторых
случаях обновлять надо, команда Auto Page Rewrite как раз для этого предусмотрена.
Описано в doc0842.pdf

Не совсем. В любом случае, атмел неплохо расписал алгоритмы работы в своих даташитах, например
См. пп7.2, 7.3 (p.8) и п11.3 (p.21) по поводу дописывания, а также на стр. 1:


Учтите, что Buffer to Main Memory Page Program without Built-in Erase делается для уже стертых страниц, а для дозаписывания
нужна Auto Page Rewrite, которая выполняется 14мс (35мс мах). Все равно это много меньше чем стирание блока у NOR.


Не стирать, а обновлять данные в нем - п11.3 (p.21). Правда, тут указано 20000 циклов, видимо, зависит от модели DataFlash.

Всем спасибо за содержательную дискуссию, узнал много полезного. Посмотрю на исходники yaffs, если получится быстро внедрить к себе -- буду использовать её. Если нет склоняюсь к собственному велосипеду.

не совсем так. так вроде бы было на старых 45-х, на тех, что с суфиксом D можно дозаписывать, проверено

В прошлый раз задача решилась использованием EEPROM и собственного велосипеда, но в этот раз вылезла с немного другого бока.
У меня по прежнему ColdFire V2, но в этот раз памяти достаточно. Решил внедрять yaffs2.
В целом всё хорошо, кроме того, что не понятно где храниться ECC. Сектор 528 байт. Из-за того, что использую yaffs2, нужно использовать inband tags. И как-то само собой получается, что ecc никто не считает.
Собственно вопрос к знатокам: как добиться того, чтобы ECC вычислялся в такой конфигурации? Или нужно обязательно использовать больший сектор (что не хочется, потому что файлы маленькие и в 100% случаев меньше 512 байт).