Проблема выбора флешовой файловой системы для at91sam7s/7x, обыкновенный spi'йный dataflash Опции

[Harbour]

Hi.

Нужна FS со следующими характеристиками :

- wear leveling (так как флеш примитивный)
- log structured или transaction based, т.е. fault tolerant
- small memory footprint (< 8k [при одном открытом файле])
- особо быстрая скорость не требуется
- совместимость с существующими FS (FAT например) нафиг не нужна

При беглом обзоре по инету из открытых нашел ELF, из закрытых lffs (symbian) и targetffs (из targetos), остальные или рассчитаны на работу с mmc./sd (т.е. wear пофиг), или жутко кушают озу.
Кто-то задавался данным вопросом ? Может есть готовые решения ? Или кто думал написать свою - можно сложить усилия, кой-какие идеи уже имеются.

P.S. Кстати а где взять более подробную инфу по lffs/targetffs ? А то как-то скупо все у них на сайте.

P.P.S Еще о NOR датафлеши от атмеля - в любой NOR флеши можно стереть страницу и потом сбрасывать биты, так сказать до упора - в доке по at45db четко написано - не рекомендуется, вопрос кто что думает по этому поводу ?

TIA

[Harbour]

дык, а как к примеру Вы будете делать readdir("/") на такой системе - всю флешку просканируете ? Затем, нужно дописать в файл - ведется типичный лог событий embedded устройства - при Вашем варианте если файл "зажат" между другими ничего не выйдет - придется или все содержимое копировать в конец и потом дописывать или строить дерево версий. А если нужно будет переписать что-то в середине файла [по правде не сильно нужная опция для embedded применений, но все же] ?

[alcosar]

дык, а как к примеру Вы будете делать readdir("/") на такой системе - всю флешку просканируете ?

Да. По времени это довольно быстро. Тем более, что начинать файл можно со страницы кратной 4 - в 4 раза быстрее.

Затем, нужно дописать в файл - ведется типичный лог событий embedded устройства - при Вашем варианте если файл "зажат" между другими ничего не выйдет - придется или все содержимое копировать в конец и потом дописывать или строить дерево версий. А если нужно будет переписать что-то в середине файла [по правде не сильно нужная опция для embedded применений, но все же] ?

Продолжать лог как новый файл.

[Harbour]

дык, а как к примеру Вы будете делать readdir("/") на такой системе - всю флешку просканируете ?

Да. По времени это довольно быстро. Тем более, что начинать файл можно со страницы кратной 4 - в 4 раза быстрее.

Справедливо только для маленьких флешек - для флешей >=64Mbit это десятки тысяч секторов, что выливается в _минуты_ поиска. В любом случае алгоритм не масштабируемый, т.е. время поиска линейно зависит от обьема носителя, что не есть good. Далее, если сделать начало файла с определенной границы, то сектора на этих границах будут иметь бОльший wear level чем данные, т.е. они быстрее накроются. А время, которое уйдет на постройку дерева версий - для такой embedded системы при рестарте уже смело можно выводить на LCD что-то типа - "откинтесь на спинку кресла" В инете полно алгоритмов, скорость сканирования dir_entries для которых, не зависит от обьема флешек.

Затем, нужно дописать в файл - ведется типичный лог событий embedded устройства - при Вашем варианте если файл "зажат" между другими ничего не выйдет - придется или все содержимое копировать в конец и потом дописывать или строить дерево версий. А если нужно будет переписать что-то в середине файла [по правде не сильно нужная опция для embedded применений, но все же] ?

Продолжать лог как новый файл.

Оно то понятно, что продолжать, а накладные расходы по памяти для дерева при этом какие ? У меня получилось (n_sect/8) + superblock + sector_buf, что для 16Mbit флеша (у меня at45db16) дает (4096/8 + 512 + 512) = 1k5 ram'ы, при монтировании [алгоритм O(1)] в самом худшем случае (пустой флеш) нужно прочитать 192 сектора, в лучшем (заполненный) - 3.

Сообщение отредактировал Harbour - Aug 10 2006, 01:58