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

Отдельные биты внутри страницы сбрасывать в ноль последовательными записями (если я правильно понял) действительно нельзя - появяться искажения других битов в этой-же странице через десяток-другой записей.

А почему не использовать "Auto Page Rewrie" - читаем страницу в ОЗУ-буфер, меняем нужные биты/байты и записываем обратно командой "Main Memory Page Programm with Built-in Erase". Таких перезаписей можно сделать уже 10000 на сектор, после чего надо стереть сектор.

Конечно за счет операции стирания страницы подобный алгоритм более медленный. Но и более надежный.

Hmm, обычно это справедливо для NAND флешей.



Да, но эти записи придется делать в другую страницу.



Ладно, где-то оно понятно, бум лепить свой вариант на wandering trees.

Если делать FS так уже и плясть от page как от блока.
Кстати, вы Ethernut не смотрели? Там точно есть поддержка fs и помоему на DataFlash (давно было, не помню).

Ну как-бы при реальной NOR флеши можно делать updat'ы секторов в так называемом in-place режиме, похоже что dataflash это комбинированный флеш , т.е. не чистый NOR, отсюда и ограничения. В принципе это не напрягает, так как log structured filesystem, которую я сейчас делаю все данные пишет в out-of-place режиме, тем самым достигается 100% устойчивость к unexpected reboots.
ethernut разумеется смотрел - модная, кстати, штука, человеческой фс там нет (simple_fs не в счет).

А вы родной атмеловский фат не смотрели? Я особенно не разбирался. Если надо - скину. Не закачался референц мануал

Сообщение отредактировал vesago - Aug 2 2006, 17:43

Вот именно! DataFlash как-бы сказать... не совсем NOR. Чегой-то там атымел намудрил... Отсюда и такие странные ограничения - и не NAND и не совсем NOR.



Почему в другую - запись именно в ту-же страницу (с Buil-in Erase). Где-то у атмела видел описание именно такого алгоритма. Единственное ограничение - контроль 10000 подобных циклов на один блок, после чего обязательное стирание блока. У меня подобного контроля не было (как и файловой системы ) т.к. было гарантированное алгоритмом стирание блока задолго до 10000 циклов. А вот один знакомый напоролся на это. Причем при некотором износе массива (~30-50%) сбои начали проявлятся при 7-8 тысячах подобных перезаписей. Правда это все со слов человека. Сам такого не наблюдал.

он есть на ftp - fusionfs называется, ненадежный он - все данные в памяти, пока не вызван close() - если к примеру в этот момент произойдет reset то нужно будет чем нибудь разгребать убитый fat, о сохранности данных даже речь не идет. fault tolerant в моем понимании это - есть на диске файл, открываем, lseek, пишем в него - в этот момент ресет - файл и fs находятся в прежнем, т.е. до открытия на зпись, состоянии.



Так в этом и фишка - если в момент этой builtin-erase операции произойдет power fail/reset - данные-то того ... т.е. updat'ит человек fat или superblock, а тут засада. NOR тем и интересен был, что новые данные накладываются на старые _без_ стирания. В общем проехали эту dataflash, алгоритм пофиксили, таперь оно и на NAND будет работать.

А что если записывать файлы один после другого по кольцу. Вся память представляет собой кольцевой буфер. Если при записи нового файла окажется, что он затрет существующий(ие), то сначала переписать его(их) в конец. Файл представляет собой заголовок в одной странице и данные. В заголовке хранятся метаданные файла - имя, размер и т. д. Страница с данными хранит данные 256 или 512 байт и метаданные страницы - тип(заголовок или данные), статус(дефектная или нет), число байт в странице(может отличатся от 256 или 512 в последней странице файла), порядковый номерстраницы, контрольная сумма.

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

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

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

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




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

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

AP-686 Intel® FlashFile™ System Selection Guide
Правда документ староват - '98 года
AP-686

Сообщение отредактировал jhoo - Aug 16 2006, 07:53

Для меня тема закрыта 600-стами строками кода. Раньше была кнопочка "Закрыть тему" - сейчас чего-то нету ;(

Как решили сделать, если не секрет?