Файловая система "Reliance Edge" - кто-то щупал?, современная альтернатива FatFs в многозадачках? Опции

[Ruslan1]

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

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

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

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

[AlexandrY]

Кто-то может похвалить или поругать?

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

[Ruslan1]

Тут в закромах лежит 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: ну и приятно если при этом можно остаться честным человеком, то есть соблюсти условия лицензии.

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

[AlexandrY]

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

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

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

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

[Ruslan1]

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

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

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

Data Exchangeability
If the media used with Reliance Edge is removable, such as a USB drive or a SD card, data on that
media can be copied to and from a Windows-based computer using the Reliance Edge Image
Copier/Image Builder command line utilities.

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

[AlexandrY]

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

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

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

[Ruslan1]

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

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

[AlexandrY]

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

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

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

[Ruslan1]

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

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

[mantech]

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

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

[jcxz]

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

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

Все можно сделать, да. Эти костыли плодятся и множатся. Надоело.

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

[Ruslan1]

Автор хочет чтобы всё уже был и ничего не дописывать:

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

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

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

[mantech]

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

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

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

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

[jcxz]

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

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

[Ruslan1]

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

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

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

[jcxz]

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

Типа так:
Создать обёртку, через которую будем вызывать функции 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-ам устройства).

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

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

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

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