флэш-раздел для записи и внезапное отключение питания

Ага, а тип памяти мы должны,ванговать?

Аккумулятор/ионистор заведомо надёжнее и проще.

Мы посоветуем 3 раздела - 1 без ФС для загрузчика и 2 раздела с JFFS2 - для read-only и для variable.

Выбор-то не особо богат - JFFS2 и YAFFS2, просто не забывайте вызывать fflush.

Память - либо SSD диск (SATA), либо compact flash. Возможно просто SD-карта в одном из вариантов. Я потому и не указал тип флэшки.

А какие флэшки лучше переживают пропадание питания? Они по-разному переносят такое событие?

Если сбои питания в момент попытки записи файла конфигурации будут происходить через раз - JFFS2 в любом случае выдержит, или есть какой-то разумный лимит на число последовательных пропаданий питания?

У меня не было прецедентов сбоя файловой системы, а вот с обнулением файлов встречался.

В STM32 EEPROM эмулируют так, нопремер.

т.е. JFFS2 не позволяет чтобы результатом сбоя питания оказался битый файл? Либо всё либо нулевой? Ну это вполне устраивает.

А файлы имеет смысл просто писать как есть, есть ли смысл еще и MD5 (например) прикладывать?

На это я не могу дать однозначного ответа, если интересно, рекомендую обратиться к спецификации на JFFS2.
Касательно MD5 вопрос не понятен, всё зависит от Ваших требований. Я, например, храню конфигурационный файл в XML и при каждом чтении/записи проверяю, если не отключено, по XMLSchema, тем самым более-менее гарантирую корректность данных.

На это я не могу дать однозначного ответа, если интересно, рекомендую обратиться к спецификации на JFFS2.

Вообще-то она говорит что jffs2 не пригодна для блочных устройств, которые собирается использовать ТС. Зачем вы ему ерунду советуете ?

Вообще-то она говорит что jffs2 не пригодна для блочных устройств, которые собирается использовать ТС. Зачем вы ему ерунду советуете?

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

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

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

Таких ФС в Linux нет. Наиболее безопасная - ext4, но полной уверенности с ней нет и не будет.

ext4 -o sync

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

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

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

Не хотелось бы полагаться на вероятности. Допустим, я научился эмулировать выключение питания в момент записи конфига +/- наносекунды.

Тогда выключить и в бункер.

Не хотелось бы полагаться на вероятности.

Последнее действие переименование. Оно выполняется как

• запись флага «идёт копирование метаданных из блока N в M»
• копирование метаданных
• запись флага «удаление после копирования»
• удаление флага «идёт копирование»
• удаление оригинальной записи
• удаление флага «удаление после копирования»

При наличии первого флага, повторит копирование, при наличии второго — удаление. На самом деле там не совсем флаг, а запись в журнал, но смысл тот же. Либо не переименуется совсем, либо при включении и монтировании доделает операцию.

Остаются вероятности, что на флэшку упадёт метеорит или сгорит блок питания и спалит всё аппаратно.

Спасибо, интересная рекомендация. Примерно такого ответа и хотелось увидеть по части методики )

Еще мысль: ведь я могу вообще без какой-либо ФС работать, если мне надо работать по сценарию с флагами - верно?