[makc 217]

1 минуту назад, haker_fox сказал:

Всё, что у меня есть

 

Reliance_Edge_Developers_Guide_PDF_781.pdf 1 MB · 0 скачиваний

Спасибо и на этом, хотя в общем-то и так было понятно что это типичная CoW файловая система. Интересовали именно детали, которые к сожалению в их патенте не описаны.

[jcxz 235]

2 минуты назад, makc сказал:

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

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

Если предположить, что работаем с безглючной картой, то даже FAT16/FAT32 можно сделать абсолютно устойчивой к сбоям питания, всего-лишь добавив журналирование транзакций в слой low-level IO того же FatFS.

[haker_fox 61]

5 minutes ago, makc said:

Интересовали именно детали

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

[makc 217]

7 минут назад, jcxz сказал:

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

Это не совсем баги реализации, скорее это "особенности". Никто ведь не заявляет, что SD-карта будет надежно работать в условии пропадания питания во время записи?

7 минут назад, jcxz сказал:

Если предположить, что работаем с безглючной картой, то даже FAT16/FAT32 можно сделать абсолютно устойчивой к сбоям питания, всего-лишь добавив журналирование транзакций в слой low-level IO того же FatFS.

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

[Herz 5]

1 час назад, haker_fox сказал:

Посмотрите Red FS от Reliance Edge. Использовал её в нескольких проектах. На порядки устойчивее Fat FS. Правда, в редких случаях, при интенсивном тестировании всё-таки сбои были. Разбираться мне время не дали, сказали, что "и так сойдёт".

А как насчёт "порога вхождения"? Я только присматриваюсь к Fat и как-то опасаюсь, что освоение займёт у меня прилично времени...

[makc 217]

36 минут назад, Herz сказал:

А как насчёт "порога вхождения"? Я только присматриваюсь к Fat и как-то опасаюсь, что освоение займёт у меня прилично времени...

Судя по API там всё довольно просто (на входе), а вот докопаться до причин проблем без описания логики и архитектуры будет проблематично (выход будет дорогой).

[mantech 49]

2 часа назад, jcxz сказал:

Журналирующая запись сделает любое небезопасное отключение, безопасным. 

А что произойдет, если сбой питания будет в момент записи в журнал? Информация пропадет по-любому... Все, что дает журналирование - это спасение ФС и не более того...

[makc 217]

42 минуты назад, mantech сказал:

А что произойдет, если сбой питания будет в момент записи в журнал? Информация пропадет по-любому... Все, что дает журналирование - это спасение ФС и не более того...

Нет совсем даже не обязательно, почитайте как устроены Copy on Write (CoW) ФС. В них ничего не пропадает, если носитель гарантирует целостность данных, которые в момент выключения питания не модифицируются.

[Tarbal 4]

On 9/7/2021 at 6:09 AM, Ruslan1 said:

Устройство безостановочно работает месяцами-годами. Периодически пишет на SD-карту. Используется FAT32 (из FatFS Чина), SDIO интерфейс.

И есть сильные подозрения, что внутренний контроллер SD карты не очень-то и выравнивает количество записей по физическим секторам. В результате появляются bad block, и время чтения некоторых секторов сильно увеличивается. Бэды появляются там, куда часто пишем (FAT). Время доступа тоже очень вырастает для части блоков.

Изношенная флеш память даст сбой в любом случае.
Если это устройство разрабатывается, то я бы сделал неотъемлимой частью проекта архивирование данных на другой носитель. К тому же регламентировать замену носителя при 75-80% износа.
В готовом устройстве такие изменения сделать труднее.
ext3 или ext4 защитят от сбоев, вызванных внезапным обесточиванием.

[jcxz 235]

2 часа назад, mantech сказал:

А что произойдет, если сбой питания будет в момент записи в журнал? Информация пропадет по-любому... Все, что дает журналирование - это спасение ФС и не более того...

Что произойдёт если сбой произойдёт перед записью? Не знаете что происходит с информацией в ОЗУ при выключении питания? Вот то и произойдёт.

Журналирование спасает от разрушения уже записанных ранее данных (и всей структуры их хранения).

[jcxz 235]

5 часов назад, makc сказал:

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

Все операции с файлами выполняем в виде отдельных безопасных транзакций. Перед такой транзакцией - стабильное валидное состояние ФС, и после завершения транзакции - другое стабильное валидное состояние. В low-level IO слой посылаем сообщение "Начало транзакции" и "Конец транзакции" соответственно - перед ней и после её завершения (в хвосте завершения не забыть сделать flush() буферов записи ФС).

По 1-му сообщению слой low-level IO открывает запись о транзакции (помечает запись как "пустая");

далее в теле транзакции слой low-level IO сохраняет в эту запись все запрошенные операции записи/стирания с секторами карты (вместе с их содержимым);

по сообщению "Конец транзакции", слой low-level IO закрывает созданную запись (помечает её как "заполненная" (точка 1)); далее - выполняет все операции, содержащиеся в этой записи; далее - удаляет запись (помечает её как "удалённая" (точка 2)).

Очевидно, что опасный интервал - между точками 1 и 2. Если в этот момент происходит перезагрузка, ФС находится в промежуточном состоянии. Тогда код монтирования слоя low-level IO, увидев валидную заполненную запись, выполняет все операции записанные в неё, и удаляет её. Очевидно, что сбой питания может произойти сколько угодно раз в этом интервале - при каждом рестарте ПО код будет выполняться заново, до тех пор, пока не успеет дойти до точки 2.

 

Как видно - никакой связи с логическим уровнем ФС у слоя low-level IO тут нет и оно ему не нужно. И тип ФС этому слою тоже по-барабану - будет работать с любой ФС.

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

 

PS: И да конечно - выдёргивать карту в таком случае можно только сделав предварительно "безопасное извлечение". Хотя и от этого можно избавиться, если журнал хранить на этой же SD, а на ПК написать драйвер, который будет выполнять ту же операцию, что и код монтирования (при обнаружении заполненной записи журнала).

[haker_fox 61]

7 hours ago, Herz said:

А как насчёт "порога вхождения"?

Чуть заморочистей (ИМХО), чем FatFS. Хотя бы потому, что настраивать эту ФС нужно специальной утилитой (была бесплатной). А так, всё стандартно: все функции понятны по их именам. Открыть файл, писать, читать, закрыть. То же самое с директориями. Пара служебных функций для разметки диска.

FatFS значительно проще. Снова же ИМХО. Возможно, потому что она всё-таки FAT и многократно где описана.

Тем не менее, внимательное вычитывание документации решает значительное количество невозникших проблем. В документации и на ту и на ту ФС описано всё, чтобы их использовать. Включая, написания драйверов IO. Кстати, RedFS позволяет взять драйвера нижнего уровня от FatFS. В обоих системах есть заготовки для их работы в различных ОСРВ. Мне была актуальна только FreeRTOS, которую мы используем на работе.

 

 

7 hours ago, makc said:

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

С этим соглашусь. Как я уже отмечал, у нас на объектах была пара сбоев RedFS. Я не смог найти причину. По-крайней мере в своём ПО. А разбираться во внутренностях RedFS без документации не было ни желания, ни времени. Сейчас снова стоит передо мной вопрос отказоустойчивой системы, я буду настаивать на собственном изготовлении. Тут хотя бы будет понятно, чей косяк и где) Кстати, а Вы не знаете подобного рода готовые хорошие ФС, пригодные для использования на bare-metal (без linux, win, qnx  ит.п. больших систем)?

[makc 217]

8 часов назад, Tarbal сказал:

ext3 или ext4 защитят от сбоев, вызванных внезапным обесточиванием.

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

6 часов назад, jcxz сказал:

Не знаете что происходит с информацией в ОЗУ при выключении питания? Вот то и произойдёт.

В ОЗУ какого типа? Статического или динамического? Они ведут себя по-разному в этих условиях.

6 часов назад, jcxz сказал:

Журналирование спасает от разрушения уже записанных ранее данных (и всей структуры их хранения).

Не всегда, см.выше про журналирование метаданных (включенное по-умолчанию) на ext3 и ext4. Хотя в целом я с вами согласен.

6 часов назад, jcxz сказал:

Как видно - никакой связи с логическим уровнем ФС у слоя low-level IO тут нет и оно ему не нужно. И тип ФС этому слою тоже по-барабану - будет работать с любой ФС.

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

2 часа назад, haker_fox сказал:

Кстати, а Вы не знаете подобного рода готовые хорошие ФС, пригодные для использования на bare-metal (без linux, win, qnx  ит.п. больших систем)?

Готовых и сразу хороших мне под свои задачи найти не удалось. Я писал свои. Одну с учётом фамильной специфики NOR-флешек серии AT45DB, вторую для 25й серии типа W25Q и им подобных. Вторая по логике работы похожа на https://github.com/pellepl/spiffs и в принципе делает то же самое, только немного по-своему и как мне кажется получше. Поэтому если у вас относительно небольшие NOR флешки, то можно взять эту spiffs и сделать на её основе своё решение.

 

[Ruslan1 17]

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

Моя проблема  именно в "затирании" и появлении bad  blocks. Раньше даже было что карточки в Read-only переключались, но там софт действительно много писал на крточку, причем малыми порциями. Переписал с тех пор сильно программу, теперь до  этого не доходит.

 

 

Я уже думал про SLC и  Industrial Grade. цена вопроса невелика по  сравнению с остальными вариантами. Но что я могу обещать? Если сейчас нефейковый SanDisk SDHC UHS-I начинает глючить через полгода-год, то другая карточка (SLC) сколько протянет, пять лет?

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

[jcxz 235]

3 часа назад, makc сказал:

В ОЗУ какого типа? Статического или динамического? Они ведут себя по-разному в этих условиях.

Одинаково - разрушается содержимое.

Цитата

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

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

Например обёртка "добавление/модификация одной записи в базе данных на диске":

1. Начало транзакции в слой журналирования.

2. Запись внутрь файла file1.data базы данных по смещению X1.

3. Запись внутрь файла file1.index базы данных по смещению X2.

4. Конец транзакции в слой журналирования.

И все операции добавления/модификации записей с этой БД должны выполняться через эту функцию-обёртку. И они станут перезагрузко-безопасными.

Цитата

Эта логика и определяет такую связь. И в существующей реализации того же FatFS ничего для этого нет, поэтому либо модифицировать FatFS

Не надо ничего модифицировать! См. выше. FatFS (или любую другую) вообще не трогаем. Она ничего не знает о нашем журналировании.

5 минут назад, Ruslan1 сказал:

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

Просто везёт. Запустите миллион ваших устройств, работающих 24/7 и непрерывно пишущих на диск.... и проблемы посыпятся потоком.

5 минут назад, Ruslan1 сказал:

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

Если нет уверенности, что выравнивание износа работает в карте, то почти единственный путь (если всё-же такие карты использовать) - реализовать собственный слой выравнивания износа на уровне low-level IO.