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

[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 журналирование по записи хочу.

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

[makc]

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

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

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

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

[segment]

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

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

[AlexandrY]

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

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

[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-карты. Ведь стираться будут только "грязные" блоки. "Грязным" считается блок, который: (в каждом секторе содержит хотя-бы один байт != стёртому содержимому (все сектора "грязные")) && (не содержащий назначенных на него логических секторов карты). Счётчики стирания блоков можно также безопасно хранить в кольцевом буфере подобно таблице переназначений секторов.
При вкл. питания счётчики также грузятся в ОЗУ. Когда нужно записать сектор и нет чистых секторов в "не грязных" блоках, только тогда выполняется стирание блока. "Грязность" блоков можно определять по факту при вкл. питания (читая все подряд, медленно) или весть журнал (быстрее).

[makc]

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

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

Wear Leveling

Wear leveling happens on full allocation groups.

The card performs wear leveling by keeping a pool of physical allocation groups that are invisible to the user and choosing a new group from that pool when writing to a new logical group, putting the previous physical group back into the pool after either the new group has been completely written, or the old data been moved over to the new group as part of garbage collection. This method is called dynamic wear leveling and guarantees that all logical allocation groups that sometimes get written to are aging at about the same rate.

The dynamic wear leveling can be easily observed by analyzing the timing for the garbage collection.

Very few SD cards use static wear leveling, which would also puts allocation groups back into the pool that are only written once during initialization of the card but remain stable afterwards. This would be necessary to maximize the expected lifetime of a memory card that is mostly filled with a typical root file system but has a few files being written constantly.

However, some CF cards are known to do static wear leveling in a way that leads to data loss when the supply voltage gets lost while the card is doing static wear leveling. This is even the case for read-only cards, since the static wear leveling can get triggered by read accesses on those cards.

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

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

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

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

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

Разве есть такие SD с блоками стирания в несколько МБ???

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

Writing to random addresses on the medium will result in read-modify-write operation being performed on a whole allocation group, because each write access requires a garbage collection. For instance on a typical SDHC card with 4 MB erase blocks, a workload writing 4 KB file system blocks to completely random locations results in a write amplification factor of 1024.

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

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

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

При вкл. питания счётчики также грузятся в ОЗУ. Когда нужно записать сектор и нет чистых секторов в "не грязных" блоках, только тогда выполняется стирание блока. "Грязность" блоков можно определять по факту при вкл. питания (читая все подряд, медленно) или весть журнал (быстрее).

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

Post Scriptum.

[mantech]

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

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

[jcxz]

Поэтому повторные частичные записи (новые записи журнала) в один и тот же блок (страницу) для NAND крайне не рекомендованы, т.к. могут повредить ранее записанные данные. К тому же с учетом вышеуказанных проблем не понятно, как гарантировать атомарность модификации самого журнала. PkUnzip.zip.

Я же написал как - использовать очередь из страниц 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-х блоков - будет идти параллельное стирание и запись страницы.

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

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

а запись журнала на SD приведет к ее скоропостижной гибели.

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

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

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

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

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

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

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

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

[mantech]

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

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

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

[jcxz]

делал на 2х таких систему с гарантированной правильной записью данных, на сд-карте такое сделать сложнее, т.к. ставить их несколько - не вариант, клиенту нужно, чтоб карты поддерживали стандартную ФС.

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

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

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