Jump to content

    

Отказоустойчивая ФС, направьте, пожалуйста, в нужном направлении

Добрый день, коллеги! В приборе, которому могут неожиданно отключить питание, необходимо сохранять логи (файлы длиной 50 - 150 кб). Допускается потеря лога в момент отключения питания (либо другого сбоя), но не разрушение ФС вместе с остальными данными. Прибор сделан на базе Cortex-M4F. Используем FreeRTOS. Из журналируемых "свободных" решений нашёл только uc/FS. Может быть есть какие-либо ещё доступные ФС с такими возможностями, пригодными для применения в embedded? В целом, не требуется совместимости с FAT, хотя и желательно.

Посоветуйте, пожалуйста, что-нибудь! Очень заранее благодарен!)))

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
5 часов назад, haker_fox сказал:

Посоветуйте, пожалуйста, что-нибудь! Очень заранее благодарен!)))

Зачем вообще какая-то ФС? Пишите в кольцо. Тогда не будет потери и в момент выкл. питания. Тем более с вашей то областью применения, потери при выкл. питания имхо - недопустимы.

Share this post


Link to post
Share on other sites

Самая надежная ФС, это её отсутствие.

Share this post


Link to post
Share on other sites

Здравствуйте, по заявлениям LittleFS, как раз предназначена для работы в таких условиях. Сам лично применял, но жестко на предмет надежности не тестировал.

https://github.com/ARMmbed/littlefs

https://os.mbed.com/blog/entry/littlefs-high-integrity-embedded-fs/

Share this post


Link to post
Share on other sites
49 minutes ago, jcxz said:

Зачем вообще какая-то ФС? Пишите в кольцо. Тогда не будет потери и в момент выкл. питания. Тем более с вашей то областью применения, потери при выкл. питания имхо - недопустимы.

Ну всё-таки в момент выключения питания потеряется минимум одна страница флеши.

 

34 minutes ago, Wese said:

Здравствуйте, по заявлениям LittleFS, как раз предназначена для работы в таких условиях. Сам лично применял, но жестко на предмет надежности не тестировал.

https://github.com/ARMmbed/littlefs

https://os.mbed.com/blog/entry/littlefs-high-integrity-embedded-fs/

Спасибо, изучу её. На всякий случай вопросы: она поддерживает несколько разделов? Совместима с FAT (полностью)? Есть ли какие ограничения, прямо не указанные на сайте?

Share this post


Link to post
Share on other sites
1 минуту назад, haker_fox сказал:

Ну всё-таки в момент выключения питания потеряется минимум одна страница флеши.

Почему? Нет конечно.

Share this post


Link to post
Share on other sites
26 minutes ago, jcxz said:

Почему? Нет конечно.

Простите, но я тогда не понимаю, как писать по кольцу? Допустим, я накапливаю на флешке файлы лога, длина которых варьируется от 50 до 150 кБ. Логов допустимо хранить 20, затем они переписываются, начиная со старшего. Т.е. сами логи пишутся в большом кольце, а внутри логи писать тоже по кольцу? Но как? Я понимаю, могу задавать тривиальные вопросы, но мне действительно не очень понятно. Буду премного благодарен, если "разъжуёте"))))

И можно ли при таком подходе писать файлы вперемешку, как на "настоящей" ФС? Например, файл лога + текстовый файл и т.п.

Share this post


Link to post
Share on other sites
12 minutes ago, haker_fox said:

Простите, но я тогда не понимаю, как писать по кольцу? Допустим, я накапливаю на флешке файлы лога, длина которых варьируется от 50 до 150 кБ. Логов допустимо хранить 20, затем они переписываются, начиная со старшего. Т.е. сами логи пишутся в большом кольце, а внутри логи писать тоже по кольцу? Но как? Я понимаю, могу задавать тривиальные вопросы, но мне действительно не очень понятно. Буду премного благодарен, если "разъжуёте"))))

И можно ли при таком подходе писать файлы вперемешку, как на "настоящей" ФС? Например, файл лога + текстовый файл и т.п.

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

Share this post


Link to post
Share on other sites
42 минуты назад, haker_fox сказал:

И можно ли при таком подходе писать файлы вперемешку, как на "настоящей" ФС? Например, файл лога + текстовый файл и т.п.

Я же говорю: без ФС. Какие файлы?? Создаёте кольцевой буфер из N1 элементов - секторов стирания флешь. Каждый сектор состоит из N2 страниц записи флешь. Каждая страница - из N3 записей. Одна запись - это одно событие лога (одна запись лога). Запись имеет фиксированный размер (можно и переменный, но сложнее и вряд-ли нужно). Дальше работаете с этим кольцом как с обычным кольцевым буфером. Поддерживая перед головой кольца (позицией записи) стёртыми не менее одной страницы (если например нужно дописать запись, а размер стёртой дырки после этого станет меньше одной страницы, то сначала стирается ещё один сектор, и только потом пишется страница).

При старте ПО надо:

1) сперва найти положение дырки (она всегда есть и она >= размеру одной страницы);

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

3) создать в ОЗУ все необходимые переменные описывающие положение в кольце (позиция записи, кол-во записей и пр.);

4) можно начинать писать новые записи в кольцо.

Для ускорения первого пункта можно увеличить минимальный размер стёртой дырки до 1-го или даже нескольких секторов стирания (если доступный объём флешь позволяет). Тогда искать дырку можно с шагом по кольцу == размеру дырки.

Продумать формат записи так, чтобы она имела заголовок + тело. По заголовку должно быть возможным определить состояние записи, одно из: 1) запись стёрта (запись внутри дырки стирания); 2) запись заполнена данными, валидна; 3) запись "плохая" (при тестировании после старта обнаружено повреждение записи (CRC и т.п.) например в результате выключения питания в процессе записи во флешь этой записи).

Очевидно, что если например исходное (стёртое) состояние ячеек флешь Вашего чипа флешь == 0xFF, то для первого состояния лучше принять значение флага: ==0xFF, для последнего == 0x00, а для 2-го - любое другое. Тогда можно превращать невалидные записи в "плохие" простой операцией записи страницы "поверх", без стирания.

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
10 минут назад, iliusmaster сказал:

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

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

Попробуйте как-нить ваше решение поставить на реальную подстанцию, где всё непрерывно клацает и переключается, а по соседним коммутируемым проводам гуляют неслабые токи.

Кроме того - что будет с вашим ионистором в диапазоне -40...+70 (который норма для подстанции)? и через несколько лет?

 

Share this post


Link to post
Share on other sites

Это решение работало на электрической пилораме с двигателями под 40 кВт, и в моменты, когда  в бревне пила напарывалась на осколок, пильная лента(спецсплав шириной 150мм и толщиной в 1.2мм) рвалась. В момент заклинивания полотна , когда спецсплав сильно сопротивлялся разрыву, мотор резко стопорился, и мы получали 100-150 квт энергии в широком спектре, излучаемыми длиннющими проводами - антеннами.

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

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

Покупайте промышленные ионисторы, рассчитанные на режим работы -40 - +70. Panasonic для некоторых серий 10 000 часов гарантирует при +65.

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

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

Share this post


Link to post
Share on other sites
21 минуту назад, iliusmaster сказал:

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

И толку что регистрировался? Ведь МК в этот момент зависал или перегружался. А для вашей системы он должен продолжать функционировать. Т.е. - класс помехоустойчивости А. А для моего варианта достаточно класса Б.

Цитата

Покупайте промышленные ионисторы, рассчитанные на режим работы -40 - +70. Panasonic для некоторых серий 10 000 часов гарантирует при +65.

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

Ну да - ещё и печку-холодильник в комплект  :shok:

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

А ещё нужно умудриться написать прошивку абсолютно без багов. Чтобы не нужен был WDT (чтобы не было перезагрузок по нему). Кто тут умеет писать гарантированно безбажные прошивки? Есть такие?  :biggrin:

Share this post


Link to post
Share on other sites
2 часа назад, haker_fox сказал:

Ну всё-таки в момент выключения питания потеряется минимум одна страница флеши

Есть память FRAM, в ней ничего не пропадет... Возможно в ней сохранять "последнюю" страницу, которую потом можно переносить во флэшь. Но только флэшь это не 100 тыс циклов, а раз в 10 меньше... Просто они пишут 10 тыс*10 блоков... И получают цифру 100 тыс...

Так что во фрам можно сохранить не только логи, но и текущее состояние. Чтобы потом, после горячего сброса стартовать не с "исходного", а с "текущего"... 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now