Перейти к содержанию

    

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
5 часов назад, haker_fox сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

https://github.com/ARMmbed/littlefs

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
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 (полностью)? Есть ли какие ограничения, прямо не указанные на сайте?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 минуту назад, haker_fox сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
26 minutes ago, jcxz said:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
12 minutes ago, haker_fox said:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
42 минуты назад, haker_fox сказал:

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

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

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

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

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

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

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
10 минут назад, iliusmaster сказал:

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
21 минуту назад, iliusmaster сказал:

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

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

Цитата

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, haker_fox сказал:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти