копаюсь в оптимизации FatFs для FreeRTOS, ну "открыл" для себя такую страницу на сайте FreeRTOS : Reliance Edge Fail-Safe File System, A Transactional Embedded File System for FreeRTOS

Поют красиво, но вот что-то я не нашел тех кто ее реально прикручивал.
FatFs хороший, но делался во времена байтов, а не мегабайтов. Нужно что-то делать с буферизацией, да и ресурсы сейчас уже не так важны как раньше- можно и побольше ОЗУ/ПЗУ потратить, в угоду удобству-скорости-надежности в случае многозадачки.
Тут они и сравнение дают с тем же FatFs.

Лицензия не самая хорошая GNU GPLv2, но вроде и продают под коммерческие продукты. Правда, непонятно сколько стоит: нужно писать и конкретно спрашивать, такое ощущение что цена будет зависеть от персональной толщины моего фейса.

Не хочется быть первопроходимцем с набиванием шишек на личной голове и остальных частях тела, может кто-то уже составил мнение об этом продукте?
Кто-то может похвалить или поругать?

В FatFS Вам никто не мешает прикрутить какую угодно буферизацию, ведь весь low-level IO - Ваш, реализуйте как больше нравится.

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

Тут в закромах лежит transaction-based highly reliable file system (HRFS) в дистрибутиве VxWorks. Вот это реально неубиваемая FS.
А Datalight скорее всего ловит на приманку.
Reliance Nitro и FlashFX Tera они уже за так не раздают.

Спасибо, посмотрю.

До позавчера я просто использовал то, что много лет назад заменило мою самописную поддержку FAT, и это в настоящее время FatFs. Когда нужны были оптимизации - то добавлял костыли в виде оптимизации(буферизация в основном) на уровне "до вызова функций FatFs".
Но вдруг нашлось полчаса времени подумать, и оказалось, что "хочется чего-то универсального". Главная хотелка- это надежный и реалтаймовый отклик в случае работы с группой разных файлов (например, десятком), из разных задач. При этом необходимо оптимизировать запись для увеличения ресурса носителя (SD-карточки), то есть вести запись ну хотя бы блоками по 2 килобайта, если данных меньше- то ничего не пишется до накопления.

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

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

Сейчас меня интересует конкретика: контроллер уровня STM32F4, операционка FreeRTOS, свободной RAM могу взять 1 мегабайт для этой файловой системы (в будущем может и больше получится). То есть ембеддед, без потуг на универсальность и расширяемость.

Вот и наткнулся на эту "прослойку". Единственный мой аргумент "за"- это то что она рекламируется на сайте FreeRTOS, ну и бренд все-таки

Хочу просто вставить что-то как замену FatFs в уже существующий проект, потратив на это как можно меньше своего времени. Может, и не туда смотрю, есть что-то не такое новое и не такое революционное.
Upd: ну и приятно если при этом можно остаться честным человеком, то есть соблюсти условия лицензии.

Кстати, они на Гитхабе есть.

Эта FS несовместима с FAT.
Т.е. придется делать еще в навесок свой файловый менеджер чтобы хоть как-то администрировать эту FS.
Вот на этом они видимо и играют. Ждут когда к ним придут за остальным.
С тем же успехом можно взять YAFFS2.

У упомянутого дистрибутива VxWorks кстати есть DosFs (совместимая с FAT) с кэшированием и тоже с защитой от сбоев.

Но пожалуй я посмотрю эту FS.

Да, несовместима, но они пишут что дают утилиту для работы:

И в Developer's Guide тоже есть раздел про это. Но нужно компилировать. Просто готовый "экзешник для винды" не дают. Вероятно, результат зависит от выбранных опций.

Да, я уже понял, что без регистрации у них ничего не взять, даже утилиту для конфигурации.
И при этом получить проект под не пойми какую среду разработки.
Тогда уж лучше Micrium. У них FAT с кэшем, терминальной оболочкой для менеджмента , журналированием, FTL движком под NAND. И дают бесплатно, в исходниках и все сразу.

Ну, это не аргумент. СлабО любой емейл действующий указать, а в разделе "фирма" и "телефон" прочерки поставить? У меня под спам два емыла выделено, еще два для общения, и еще два для тестов
А NAND мне сейчас не нужен, так что не аргумент. И цены микриумовские меня так испугали еще лет 15 назад, что я к ним стараюсь больше не подходить.
Ну и "ФАТ с кэшем" это как-то недостаточно революционно, если все равно менять (мало дополнительных плюшек при похожем объеме нужных для перехода работ).

Убивает скорее то, что надо будет каждый раз конвертировать образ файловой системы какой-то убогой утилитой командной строки.
А образ то может быть гигабайтный. Это не вариант.

Я применял FAT-ы от Keil, Nucleus, MQX, Micrium (6-и летней давности), FatFS и они все показывали плохой риалтайм, хотя у большинства был кэш.
Может быть последние SD карты класса V90 что-то меняют, но подешевеют они не скоро.
Зато Serial NAND нынче очень быстрые и дешевые.

Это очень серьезный аргумент. Согласен, им надо что-то делать для продвижения в массы.

Просто надо сделать что-то вроде плагина ФС EXT для тотал коммандера и все

Массы устроит только FAT, увы Утилиты/плагины/драйверы суть костыли и неудобство.

Я их утречком сегодня спросил про возможность доступа к отдельным файлам (read/write/delete), если вставлю эту SD-карту в Windows PC. Ответили в течении пары часов (что уже само по себе уже очень приятно).
В-общем, нет в Винде пока счастья, а вот в Линуксе вроде уже да:

Есть еще иной выход.
Реализовать USB MTP класс.
Под виндами смартфоны дают броузить свое содержимое как раз через MTP класс.
https://www.segger.com/products/connectivit...-ons/mtp-class/

На крайний случай развернуть TCP стек и FTP сервер на нем через USB CDC EEM.

Звучит как "Просто написать файловую систему". ну-ну...
Автор хочет чтобы всё уже был и ничего не дописывать:

А с плагином это нужно будет кроме того что его написать, так ещё и переписывать под каждую новую винду или новую версию TC.
И не все юзеры знают, что такое TC. А другие юзеры - упёртые линуксоиды

Итого, есть два пути:
#1: использовать любую (надежную но нестандартную) файловую систему, и в параллель поддерживать программу (устройство) для доступа к ее файлам на компьютере.
#2: использовать FAT32.

(1) требует значительных усилий в начале и дает выигрыш в качестве хранения данных, но зато проигрывает в комфорте.
а еще в варианте (1) любая проблема очень сложно отлаживается, если оно не работает с ходу и нужно разбираться руками что на крточке не так: в отличии от FAT, такую карточку просто так не посмотришь на PC с помощью разных удобных программок. Так как никаких программок-то и нет.

Есть над чем думать.
Наверное, все-таки нужно думать про вариации (2). То есть тот же FAT, но с невидимым конечному пользователю "костылем" внутри, например с журналированием как у Микриума.

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

Резервный источник питания только для ФС? Вот уж действительно - дурь.
И даже там где он есть, он не поможет от reseta из-за помехи.
Надёжность (если говорить об устойчивости к сбоям питания/сбросам) несложно реализуется добавлением к стандартной FAT простой функции журналирования всех write-операций. Можно и FatFS доработать (сделать обёртку для неё).

вооооот! наконец-то я понял, чего же я реально хочу от этой жизни.
Добавить к FatFS журналирование по записи хочу.

Неужели никто еще не сделал?
Как бы это сделать с минимальными телодвижениями, не изобретая велосипед? смотреть в Микриуме?

Допустим, что в качестве носителя microSD или EMMC. Как это сделать надежно и просто, если размер EU (EraseUnit) на них несколько МБ? При этом атомарность записи на носитель никем, как я понимаю, не гарантируется, т.к. мы не знаем как работает внутренний механизм выравнивания износа.




Быстро, качественно и недорого. Выбирайте 2 из трех.

Кто-нибудь реализовывал MTP Device class? Что-то не нахожу примеров для столь популярного stm32

В Nucleus Plus выложена полная реализация в исходниках.

Типа так:
Создать обёртку, через которую будем вызывать функции FatFS. Обёртка сериализирует доступ к API (семафор) по модификации. Внутри обёртка для каждого такого обращения извне создаёт полную запись в журнале о затребованной операции. Этот журнал может из себя представлять либо кольцевой буфер в некоей flash (например - часть объёма этой же самой SD не занятая FS; или в отдельном чипе flash-памяти) либо в дополнительной non-volatile памяти (FRAM, etc.). Если производится запись в некий файл, то выполнится следующая последовательность действий:
1. Вход в API, захват семафора. Создаём запись журнала об данной операции. Инициализируем в ОЗУ кеш модифицированных в данной операции секторов SD.
2. В течение API-вызова: операции чтения секторов SD-карты пропускаем через кеш на сектора карты (сектора наличествующие в кеше - читаем из него, отсутствующие в кеше - читаем непосредственно с SD). Операции записи пишем в журнал (номер сектора + записываемое содержимое). А также записываемые сектора добавляем в кеш в ОЗУ (в сектора на SD пока не пишем!).
3. В конце API-вызова в записи журнала ставим флажок == запись валидна.
4. Сбрасываем весь ОЗУ-кеш в сектора SD.
5. Снимаем флажок валидности записи журнала.
6. Покидаем API, отпускаем семафор.
Теперь создаём процедуру монтирования журналированной записи в FAT. Эта процедура вызывается при каждом старте ПО устройства. Она смотрит: если флажок валидности записи журнала установлен, то выполняет все записи, которые описаны в этом журнале. После чего сбрасывает флажок (записи желательно выполнять с предварительной верификацией целевого содержимого SD, чтобы не переписывать поверх одинаковые данные).
Теперь, если произойдёт сбой где-то между 3-м и 5-м пунктами, то процедура монтирования восстановит структуру SD. Если сбой будет внутри процедуры монтирования, то она перезапустится ещё раз и ещё, пока всё не восстановит.
Если жалко ОЗУ, то можно обойтись без кеша, использовав в качестве него саму запись журнала (так как она содержит данные записываемых секторов). Будет просто немного медленнее.
Пункты 1 и 6 - выполняем "на верху", выше вызовов API FatFS; остальные пункты - "ниже" FatFS (там где она вызывает low-level IO API).
Таким образом мы сделали каждый доступ к нашему API атомарным (по отношению с reset-ам устройства).

Вот примерно так. Ничего сложного как видите


Я думаю, что внутренний механизм выравнивания износа должен быть устойчив к внезапным сбоям питания. Т.е. - в нём должно быть своё журналирование. Это вполне реально сделать. Ведь сперва из стираемого блока все валидные сектора переписываются в чистые сектора (нет записи "поверх" других данных, а значит такая запись безопасна).
И только потом делается запись в некоей структуре о переназначении сектора и блок метится как "грязный". Атомарность этих последних операций должна чем-то обеспечиваться внутри. Например - тем же журналированием.
Я бы например в некоей служебной области SD-карты завёл кольцевой буфер куда писал бы все операции переназначения секторов и, периодически (через N таких записей), скидывал туда полную карту переназначения. При включении питания находил в этом кольцевом буфере ближайшую полную карту (от головы кольца), читал её в ОЗУ, читал все модификации отдельных переназначений после неё и далее работал с ней в ОЗУ.
Тогда все операции будут безопасны.

Разве есть такие SD с блоками стирания в несколько МБ???
Размер блока стирания никак не влияет на возможность создания безопасной (атомарной) модификации SD-карты. Ведь стираться будут только "грязные" блоки. "Грязным" считается блок, который: (в каждом секторе содержит хотя-бы один байт != стёртому содержимому (все сектора "грязные")) && (не содержащий назначенных на него логических секторов карты). Счётчики стирания блоков можно также безопасно хранить в кольцевом буфере подобно таблице переназначений секторов.
При вкл. питания счётчики также грузятся в ОЗУ. Когда нужно записать сектор и нет чистых секторов в "не грязных" блоках, только тогда выполняется стирание блока. "Грязность" блоков можно определять по факту при вкл. питания (читая все подряд, медленно) или весть журнал (быстрее).

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



Таким образом, если экстраполировать описание проблем с CF на SD (алгоритмы схожи), то возможны проблемы с целостностью данных.



Журналирование - это прекрасное слово, но все сводится к техническим возможностям используемой памяти. Если бы в картах была область NOR или FRAM, с произвольным доступом к отдельным битикам, то я бы не видел проблем с реализацией, а здесь речь идет о NAND в качестве физической основы, к тому же NAND типа MLC/TLC с низким числом циклов перезаписи и поэтому честное и надежное журналирование на такой базе сделать с моей точки зрения проблематично, особенно при учете использования в картах примитивных МК с небольшой по размеру ОП.



Это логично, на SPI-flash типа NOR я так и делал. Но для NAND есть одна проблема: program disturb (см., например, Yaffs NAND flash failure mitigation). Поэтому повторные частичные записи (новые записи журнала) в один и тот же блок (страницу) для NAND крайне не рекомендованы, т.к. могут повредить ранее записанные данные. К тому же с учетом вышеуказанных проблем не понятно, как гарантировать атомарность модификации самого журнала. PkUnzip.zip.



Есть, если посмотреть значения AU_SIZE на современных картах (регистр SD Status), то там мегабайты. Цитата из вышеуказанной статьи с linaro.org:


Поэтому пытаться вести журнал на картах памяти, записывая туда по чуть-чуть в разные места - прямой путь к убийству карты. При записи в два разных места карты, удаленных друг от друга на величину большую AU, будет получаться фактическая перезапись со стиранием и GC сразу двух больших блоков, размером около 4 МБ. Поэтому Ваше предложение на мой взгляд не очень хорошо подходит для работы на SD/FatFs, т.к. ОЗУ обычно и так мало, дополнительной NOR/FRAM у нас обычно нет (мы ведь хотим сэкономить!?), а запись журнала на SD приведет к ее скоропостижной гибели.



Формально Вы правы, но доступные описания механизмов Wear Leveling на SD/MMC говорят о другом.



Времени на это при включении нет, т.к. у карт жестки временные требования по доступности к чтению/записи.

Post Scriptum.

Можете шутить сколь угодно, но ИБП реально помогает, проверял на практике по кол-ву сбоев ФС при записи... А вот насколько эффективно ваше журналирование при внезапных сбросах - эт еще можно поспорить, а вот в несколько раз быстрее убить карту памяти - так это сколь угодно. И второе, внезапные сбросы - эт уже не программная проблема, а, как правило, "плохая" аппаратка.

Я же написал как - использовать очередь из страниц FLASH.
И зачем тут "повторные частичные записи в одну и ту же страницу"? Я разве где-то предлагал такое? Да, если будет такая возможность, то будет лучше, но и без этого можно обойтись. Посредством очереди страниц. И размер блока стирания тоже не очень важен (к тому же в служебной области блок стирания (как и страница) может быть меньшего размера, чем в области данных - это думаю несложно сделать технологически).
Предположим что:
В служебной области SD страница == N байт, в блоке == K страниц. Создаём очередь из M блоков (M>=2). (где: "страница" - минимальный записываемый элемент данных; "блок" - минимальный стираемый элемент данных). Стёртое состояние: содержит все биты ==0. Страница содержащая все 0 - "чистая", хотя бы в одном байте не 0 - "грязная".
Работаем с очередью так, чтобы:
1) внутри неё всегда был как минимум один стёртый блок;
2) запись страниц шла в порядке увеличения их номеров.
Тогда при вкл.питания ищем первую чистую страницу с шагом K от начала очереди (поиск должен учитывать кольцевой характер очереди). Далее от найденной страницы ищем в сторону уменьшения номеров (опять - по кольцу) первую "грязную" страницу. Найденная страница - "голова очереди".
Каждая грязная страница содержит заголовок определённого формата и CRC всего содержимого. Заголовок обязательно содержит байты != 0.
Теперь, когда нужно добавить запись журнала в такую очередь, разбиваем тело записи на страницы, каждую страницу снабжаем заголовком и CRC. В заголовке первой страницы записи журнала указываем ID="первая_в_записи", в заголовках остальных=="тело_записи". Пишем в очередь эти страницы начиная с конца ("первая_в_записи" будет записана последней в очередь).
При записи страниц в очередь не забываем держать перед "головой очереди" дырку из как минимум одного стёртого блока! (т.е. - если хотим добавить очередную страницу в очередь, а перед ней всего K чистых страниц, то сперва стираем следующий блок и только потом пишем эту страницу).
Здесь создание записи журнала завершено и можно выполнять опасные операции с секторами SD, описанные в данной записи.
По завершении опасных операций удаляем запись журнала. Делаем это записью в очередь страницы с заголовком ID="удалено" (тело данных пустое). Таким образом с этого момента запись журнала в очереди считается удалённой.
Теперь, при вкл.питания, сначала ищется дырка из как минимум K стёртых страниц и последняя грязная страница (как описано выше). Потом считываются страницы начиная с неё. Если в результате обнаружена последовательность из страниц: ID=="первая_в_записи" и потом ID=="тело_записи" и у всех структура заголовка валидна и CRC валидно, значит у нас есть запись журнала. Выполняем её. Затем стираем (пишем в очередь страницу с ID="удалено").
С таким алгоритмом нам почти не важны конкретные значения N, M, K. А также нам не нужна возможность записи "поверх". Также нам не страшны случаи когда запись страницы (или стирание блока) прерывается сбоем питания (т.к. каждая "грязная" страница имеет заголовок определённой структуры и CRC). Конечно запись страниц в журнал будет задерживаться в моменты когда происходит увеличение дырки из стёртых страниц (как минимум K штук), но это время можно уменьшить, разместив блоки в разных физических регионах с независимым стиранием/записью, сделав чередование блоков в очереди и увеличив размер дырки до 2-х блоков - будет идти параллельное стирание и запись страницы.


Как я показал выше - это не страшно, просто очередь будет немного больше (в байтах), так как она должна занимать целое число блоков (M) и M>=2.


Помещение записи журнала внутрь очереди блоков этого не допустит как видно из вышеизложенного.
Я организовывал хранение журналов событий в своих устройствах описанным выше способом (немного сложнее в реальности). Не для wear leveling конечно, для других целей.


Тут конечно мне судить трудно как именно там делают. Я только говорю о том, что вполне возможно сделать атомарную устойчивую к сбоям модификацию SD даже имея в своём распоряжении только NAND.
А как именно делают в конкретных реализациях - вполне допускаю что гораздо кривее. К сожалению в современной реальности быдлокодеров гораздо больше чем нормальных программистов. Даже в серьёзных конторах.


Опять же - не могу знать как там в картах, но у меня на Cortex-M процесс монтирования такой службы занимал несколько сотен мкс насколько помню (dual SPI-flash 30МГц через DMA параллельно с анализом считанных данных CPU). Если подобрать другие значения N,K,M и с аппаратным ускорением то думаю и в несколько десятков мкс уложиться можно.


Во-первых: я и не спорил что "может помогать". Но это очень дорогое решение и такой ИБП может быть дороже чем всё устройство в целом.
Во-вторых: я реализовывал на практике системы с устойчивой к сбоям модификацией данных во FLASH. Да, сперва мы тоже делали расчёт на монитор питания, чтобы по его сигналу корректно закрывать все записи. Так вот - в реале это работает очень плохо! Уже не говоря о том, что сама реализация источника с гарантированным временем удержания питания после аварии очень сложная и дорогая (жёсткие требования по большому диапазону допустимых питающих напряжений). Так ещё и выяснилось, что могут быть сбросы как по срабатыванию супервизора питания, WDT и пр. Так и всякие сбои из-за программных ошибок (а Вы пишете абсолютно безглючный код? и вся ваша команда так пишет? все несколько МБ исходников?
И дальше - а как собственно отлаживаться и писать ПО (в процессе написания которого будет дофига сбоев) если при каждом таком сбое рушится вся система хранения данных и данные теряются потому, что весь расчёт - на монитор питания???)
И что значит ""плохая" аппаратка"? То что Вы предлагаете, требует чтобы устройство соответствовало классу функционирования A по ГОСТу помехоустойчивости. А это очень жёсткое требование, труднодостижимое. Использование моего алгоритма снижает требования к аппаратной части до класса B.

Так что в результате отказались от монитора питания как от дорогой и неудобной вещи. А бессбойное хранение сделали подобно тому как я описал выше (в реале там всё сложнее). Сделали один раз и потом голова больше не болела ни при отладке ни испытаниях ни при опытной эскплуатации. И сейчас эти устройства уже несколько лет продаются по несколько тыс.шт в месяц и данные в них не теряются! Хотя питание в них отключается непредсказуемо.
Конечно там не SD, а просто несколько шт. SPI-flash, но это роли не играет.

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

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

Если следовать моему алгоритму, то 2 шт. - не нужны. Всё можно сделать на одной.
В наших (упомянутых мной выше устройствах) 2 шт. SPI-flash мы ставили не для неубиваемости, а для уменьшения времени блокировки из-за операций стирания/записи.


Неубиваемые сбоями питания/перезагрузками в произвольные моменты времени - существуют.
Как - журналирующая модификация, например. И другие способы есть, если подумать. Ну естественно надо ещё схему сделать правильно.