Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Проблема выбора флешовой файловой системы для at91sam7s/7x
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
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
KiV
Цитата(Harbour @ Aug 1 2006, 14:41) *
P.P.S Еще о NOR датафлеши от атмеля - в любой NOR флеши можно стереть страницу и потом сбрасывать биты, так сказать до упора - в доке по at45db четко написано - не рекомендуется, вопрос кто что думает по этому поводу ?


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

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

Конечно за счет операции стирания страницы подобный алгоритм более медленный. Но и более надежный.
Harbour
Цитата(KiV @ Aug 2 2006, 10:38) *
Цитата(Harbour @ Aug 1 2006, 14:41) *

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


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



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

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


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

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


Ладно, где-то оно понятно, бум лепить свой вариант на wandering trees.
beer_warrior
Цитата
Да, но эти записи придется делать в другую страницу.

Если делать FS так уже и плясть от page как от блока.
Кстати, вы Ethernut не смотрели? Там точно есть поддержка fs и помоему на DataFlash (давно было, не помню).
Harbour
Ну как-бы при реальной NOR флеши можно делать updat'ы секторов в так называемом in-place режиме, похоже что dataflash это комбинированный флеш , т.е. не чистый NOR, отсюда и ограничения. В принципе это не напрягает, так как log structured filesystem, которую я сейчас делаю все данные пишет в out-of-place режиме, тем самым достигается 100% устойчивость к unexpected reboots.
ethernut разумеется смотрел - модная, кстати, штука, человеческой фс там нет (simple_fs не в счет).
vesago
А вы родной атмеловский фат не смотрели? Я особенно не разбирался. Если надо - скину. Не закачался референц мануал sad.gif
KiV
Цитата(Harbour @ Aug 2 2006, 13:58) *
Hmm, обычно это справедливо для NAND флешей.


Цитата(Harbour @ Aug 2 2006, 15:51) *
похоже что dataflash это комбинированный флеш , т.е. не чистый NOR, отсюда и ограничения.


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

Цитата(Harbour @ Aug 2 2006, 13:58) *
Да, но эти записи придется делать в другую страницу.


Почему в другую - запись именно в ту-же страницу (с Buil-in Erase). Где-то у атмела видел описание именно такого алгоритма. Единственное ограничение - контроль 10000 подобных циклов на один блок, после чего обязательное стирание блока. У меня подобного контроля не было (как и файловой системы smile.gif ) т.к. было гарантированное алгоритмом стирание блока задолго до 10000 циклов. А вот один знакомый напоролся на это. Причем при некотором износе массива (~30-50%) сбои начали проявлятся при 7-8 тысячах подобных перезаписей. Правда это все со слов человека. Сам такого не наблюдал.
Harbour
Цитата(vesago @ Aug 2 2006, 20:26) *
А вы родной атмеловский фат не смотрели? Я особенно не разбирался. Если надо - скину. Не закачался референц мануал sad.gif

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

Цитата(KiV @ Aug 3 2006, 00:03) *
Цитата(Harbour @ Aug 2 2006, 13:58) *

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


Цитата(Harbour @ Aug 2 2006, 15:51) *
похоже что dataflash это комбинированный флеш , т.е. не чистый NOR, отсюда и ограничения.


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

Цитата(Harbour @ Aug 2 2006, 13:58) *
Да, но эти записи придется делать в другую страницу.


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


Так в этом и фишка - если в момент этой builtin-erase операции произойдет power fail/reset - данные-то того ... т.е. updat'ит человек fat или superblock, а тут засада. NOR тем и интересен был, что новые данные накладываются на старые _без_ стирания. В общем проехали эту dataflash, алгоритм пофиксили, таперь оно и на NAND будет работать.
alcosar
А что если записывать файлы один после другого по кольцу. Вся память представляет собой кольцевой буфер. Если при записи нового файла окажется, что он затрет существующий(ие), то сначала переписать его(их) в конец. Файл представляет собой заголовок в одной странице и данные. В заголовке хранятся метаданные файла - имя, размер и т. д. Страница с данными хранит данные 256 или 512 байт и метаданные страницы - тип(заголовок или данные), статус(дефектная или нет), число байт в странице(может отличатся от 256 или 512 в последней странице файла), порядковый номерстраницы, контрольная сумма.
Harbour
дык, а как к примеру Вы будете делать readdir("/") на такой системе - всю флешку просканируете ? Затем, нужно дописать в файл - ведется типичный лог событий embedded устройства - при Вашем варианте если файл "зажат" между другими ничего не выйдет - придется или все содержимое копировать в конец и потом дописывать или строить дерево версий. А если нужно будет переписать что-то в середине файла [по правде не сильно нужная опция для embedded применений, но все же] ?
alcosar
Цитата(Harbour @ Aug 9 2006, 08:43) *
дык, а как к примеру Вы будете делать readdir("/") на такой системе - всю флешку просканируете ?

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

Продолжать лог как новый файл.
Harbour
Цитата(alcosar @ Aug 9 2006, 20:46) *
Цитата(Harbour @ Aug 9 2006, 08:43) *

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

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


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

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

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


Оно то понятно, что продолжать, а накладные расходы по памяти для дерева при этом какие ? У меня получилось (n_sect/8) + superblock + sector_buf, что для 16Mbit флеша (у меня at45db16) дает (4096/8 + 512 + 512) = 1k5 ram'ы, при монтировании [алгоритм O(1)] в самом худшем случае (пустой флеш) нужно прочитать 192 сектора, в лучшем (заполненный) - 3.
jhoo
AP-686 Intel® FlashFile™ System Selection Guide
Правда документ староват - '98 года
AP-686
Harbour
Для меня тема закрыта 600-стами строками кода. Раньше была кнопочка "Закрыть тему" - сейчас чего-то нету ;(
alcosar
Как решили сделать, если не секрет?
Harbour
Идея размещения и поиска суперблока взята из jffs3 - сделал 3 chain-блока + anchor area + superblock, деревья вообще не делал так как мне запись в середину файла пока не нужна - на флеше лежат прошивки для DSP/FPGA и логи, которые всегда добавляются в конец. При монтировании строится bitmap свободных секторов исходя из данных суперблока, и по версии транзакции вычисляется последний записанный сектор - с него и продолжается запись. Получилось 600 строк на Ц + 100 строк тестов, ram - 2.7k, data 10k. (собрано gcc с -O3).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.