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


8

В настоящее время я работаю над проектом, который предполагает быструю непрерывную регистрацию довольно специфичной для приложения метрики в течение длительного срока. Для этого я использовал NXP M0 и флэш-чип SPI 32 МБ. Регистрация ведется непрерывно и должна длиться много лет в полевых условиях (10+) и периодически проверяется человеком на предмет выявления тенденций. В конце концов буфер заполняется и начинает перезаписывать старые данные, что совершенно нормально. Я придумал простой алгоритм обхода всего флэш-устройства, чтобы найти текущую головку после включения питания (устройство довольно часто выключается вне моего контроля), поэтому ведение журнала может просто продолжаться с того места, где оно остановилось. Я могу просто перебрать силу и пройти это с ~ 4s в худшем случае.

Это заставило меня задуматься, существуют ли какие-либо файловые системы со структурой журналов, предназначенные для флэш-устройств и микроконтроллеров? JFFS и все другие хорошо известные структурированные журналы FS, которые я представляю, были бы немного тяжелыми для простого микроконтроллера (конечно, зависит от применения). Чтобы быть более конкретным, я хотел бы знать о любых алгоритмах, которые специально разработаны для циклического журнала с быстрым временем поиска и / или алгоритмов, разработанных для «традиционной» файловой системы на флэш-устройстве, которое может быть запущено на микроконтроллер. Традиционно в этом смысле он находится на одном уровне с чем-то вроде JFFS, где есть структура данных, представляющая коллекцию изменяемых файлов произвольного доступа в иерархическом пространстве имен.


FAT32 или FAT16 на SD-карте слишком медленные?
Викачу

2
Этот вопрос полностью относится к теме здесь, но если вы не получите хороших ответов, StackOverflow может помочь. Будем надеяться, что мы сможем получить здесь хорошие ответы!
Kellenjb

@vicatcu Не то, чтобы это было слишком медленно, для моего приложения SD-карта плюс разъем более дорогой, а SD-карты могут быть менее надежными. Kellenjb Я не был уверен, где это поставить. Подобно множеству вопросов о встроенном дизайне, этот тип падает посередине. Если бы здесь не получилось, я бы с удовольствием переместил это.
Крис Бансен,

Это сырой флеш чип? Если так, как вы справляетесь с мертвыми блоками? Довольно большая часть реализации Flash FS связана с мертвыми блоками. Если вы чувствуете, что JFFS / JFFS2 слишком тяжелый, вы можете попробовать YAFFS. Это похоже на очень простую файловую систему, по крайней мере, поэтому она должна быть достаточно легкой.
Лев

Да, это так. Плохие блоки не так уж страшны в этом конкретном приложении, поскольку его столь длительный срок, что извлекаемые данные - это просто грубая тенденция, и в большинстве случаев я сомневаюсь, что регистрация будет вообще использоваться.
Крис Бансен,

Ответы:


2

структура данных веревки

Я очарован структурой данных веревки, У меня есть хобби-проект, в котором я пытаюсь адаптировать его к микроконтроллеру с несколькими байтами ОЗУ, подключенными к огромной флэш-памяти, чтобы я мог вставлять, удалять и иным образом произвольно редактировать текст переменной длины в огромных текстовых файлах. Текстовые файлы слишком велики, чтобы поместиться в ОЗУ. Стирание последней половины файла и перезапись его во флэш-память, смещение на один байт, каждый раз, когда я вставляю или удаляю символ в середине текстового файла размером в несколько мегабайт, будет слишком медленным, но структура данных веревки может сделать это намного быстрее Поскольку структура данных веревки может представлять такие изменяемые файлы произвольного доступа с переменной длиной, как неизменяемые фрагменты фиксированной длины, кажется, что это хорошее совпадение с флэш-памятью - все изменения записываются в форме кругового журнала. Увы, все ошибки в моем коде еще не проработаны. :-(

хронологические журналы фиксированной длины

Я получил аналогичную систему циркулярного журнала для продукта, который помог разработать.

Я просто писал записи фиксированной длины одну за другой, заполняя flash как круговой массив.

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

Я позаботился о том, чтобы всегда было как минимум 2 стёртых «блока стирания», готовых для записи. После записи записи, если после нее оставалось только 2 «стертых блока», которые были пустыми, я безоговорочно удалял самый старый блок данных - 3-й блок самых старых данных после 2 «стертых блоков». (Ближе к концу флеш-памяти «после» означает «переход к началу флеш-памяти». (Возможно, одного стертого блока было бы достаточно - я забыл, почему мне показалось, что мне нужно как минимум 2, а иногда и 3). ,

Я точно забыл, сколько записей я поместил в каждый «блок стирания», но я позаботился о том, чтобы у меня никогда не было записей, перекрывающих два блока стирания - первые 2 байта каждого блока стирания флэш-памяти были либо «стертым» значением 0xFFFF, либо первые два байта контрольной суммы Fletcher-16 (которая никогда не равна 0xFFFF) в заголовке каждой записи.

Это позволило быстро сканировать его при следующем включении и найти заголовок циклического журнала - мне нужно было только взглянуть на первые два байта каждого блока стирания, чтобы различить «стертые» и «блоки данных». (Я немного беспокоился о «сбое питания в середине стирания блока», в результате чего первые два байта были стерты до 0xFFFF, но оставил не стертые байты в середине блока, поэтому я написал код для проверки микроконтроллером для этого и перезапустите процесс «стереть блок»).

Пожалуйста, сообщите мне, если вы найдете другие дружественные для флэш-памяти структуры данных или файловые системы


Ваш подход звучит несколько похоже на мой. Я бы предложил добавить еще один небольшой поворот: зарезервируйте пару байтов в каждом блоке, чтобы указать, что он «запущен» и «заполнен». Все блоки, кроме стертых, должны иметь запрограммированные биты запуска. Когда пришло время стереть блок, установите «полный» байт в последнем байте данных, затем стерте блок, а затем немедленно установите «начальный» бит самого старого стертого блока. При запуске, если вы видите, что «последний» блок является «полным», а не «запущенным», повторите удаление.
суперкат

Такой подход может показаться излишним, но если флэш-блок частично стерт, байты могут произвольно принять решение прочитать FF или что-то еще. Тот факт, что блок выглядит пустым, не является гарантией того, что биты не появятся там самопроизвольно. Если вы теряете мощность во время удаления, подождите немного при следующем запуске, а затем повторите удаление, даже если блок кажется пустым .
суперкат

Спасибо за информацию, я посмотрю на нее немного глубже, когда я на самом деле нажму на код для флэш-памяти и дам вам знать, что происходит.
Крис Баннсен,

@supercat: Спасибо, это звучит как отличная идея.
Дэвидкари

@ davidcary: я не знаю, что у меня когда-либо был блок, который выглядел полностью пустым и отсутствовал, но у меня был блок, который давал бы разные результаты при последовательных чтениях. Возможно, что блок был неверно прочитан как пустой, мой код все равно пытался его запрограммировать, что привело к нечетной путанице новых запрограммированных данных и старому мусору с прерывистым стиранием. В любом случае, сценарий, в котором блок иногда будет казаться пустым, вряд ли является нереальным.
Суперкат

0

Прошло уже довольно много лет, но я хотел бы продолжить, если кто-нибудь еще пройдет мимо. Похоже, что в настоящее время существует несколько проектов, которые активно поддерживаются (по состоянию на январь 2020 года) и представляют собой файловые системы, предназначенные для микроконтроллеров, предназначенных для флэш-памяти NOR SPI.

Обратите внимание, что я не проверял их ни в каком качестве, но они делают именно то, что искал исходный вопрос: «... структура данных, которая представляет собой набор изменяемых файлов с произвольным доступом ...»

https://github.com/ARMmbed/littlefs - Создано ARM, лицензировано BSD

https://github.com/joembedded/JesFs - на самом деле не похоже на лицензию, но было специально разработано для SPI NOR flash.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.