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

[mvb]

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

Спасибо.

[gosha]

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

Спасибо.

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

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

[mvb]

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

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

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

[aaarrr]

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

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

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

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

[AlexandrY]

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

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

[mvb]

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

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

[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 поведение" рассчитывать вообще нельзя.

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

[aaarrr]

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

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

[vshemm]

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

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

EEPROM emulation (bit or byte alterability) is easily handled with a self-contained three step read-modify-write operation.

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

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

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

[mvb]

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

[aoreh]

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

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

[mvb]

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

[Harbour]

меня в свое время (2006 год) впечатлили теоретические разработки LogFS (JFFS3) - там изначально был пофиг любой сбой на флеше. прототип FS с десятком ф-ий был написан за пару дней :

Код

extern s8 tffs_format();
extern s8 tffs_ls();
extern s8 tffs_mount();
extern tffs_file_t *tffs_dir(char op);
extern tffs_fd tffs_open(const char *name, char flags);
extern s8 tffs_close(tffs_fd fd);
extern tffs_size_t tffs_read(tffs_fd fd, unsigned char *buf, tffs_size_t len);
extern tffs_size_t tffs_write(tffs_fd fd, unsigned char *buf, tffs_size_t len);
extern tffs_size_t tffs_seek(tffs_fd fd, tffs_size_t offset, char whence);
extern s8 tffs_unlink(const char *name);
extern s8 tff_rename(const char *old_name, const char *new_name);

пахало на avr/arm с атмеловскими AT45DBxxx, правда проект так никуда особо не пошел