[tgruzd 11]

10 минут назад, Forger сказал:

Ну там же написано в описании - теряется последний сохраняемый файл, если его изменения не успели записаться в FAT.

Ну ок.  Я использовал немного другой подход, когда нужно было много мелких записей писать на SD в разные файлы (не знаю, журналирование это или нет): Файлы открывались при старте  системы и не закрывались, условно, никогда.  Кэширование делал на уровне самих записей, то есть, накапливал их буфере для каждого файла (типичный размер самой записи был кратно меньше размера сектора, типичный размер буфера перед записью - как повезёт, зависит от интенсивности потока данных), после записи сразу f_sync. Да, конечно, данные за последние пару миллисекунд могли и потеряться. Но такого, чтобы файл терялся или ФС повреждалась не замечал.

[Forger 24]

12 minutes ago, tgruzd said:

Файлы открывались при старте  системы и не закрывались, условно, никогда.

Если нет встроенного кэширования, сам факт закрытия ни на что не влияет, кроме освобождения структуры FILE в ОЗУ для хранения данных для доступа к файлу.

12 minutes ago, tgruzd said:

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

Помимо данных файла еще необходимо обновлять структуру кластеров в FAT таблице. Поддержка ДВУХ таблиц позволяет восстановить из целой сбойную FAT.

Данные и FAT находятся в разных участках "диска" и поэтому обновляются поочередно.

Достаточно оборвать запись сектора по адресам таблиц FAT, чтобы сломать файловую систему. 

Ошибки FAT может найти и исправить встроенная в винду утилита chkdsk.

 

12 minutes ago, tgruzd said:

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

Это вовсе означает что этого не было ))

[tgruzd 11]

32 минуты назад, Forger сказал:

Это вовсе означает что этого не было ))

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

32 минуты назад, Forger сказал:

Если нет встроенного кэширования, сам факт закрытия ни на что не влияет, кроме освобождения структуры FILE в ОЗУ для хранения данных для доступа к файлу.

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

Изменено 10 декабря, 2022 пользователем tgruzd

[smart_pic 7]

Всего то нужно научиться писать неблокирующие программы для кооперативной ОС, грамотно пользоваться прерываниями и аппаратными возможностями МК и тогда будет легко писать как для 8-ми битников , так и моделей покруче.

Можно ли На МК сделать красивый ВЕБ , поднять кучу функционала, управлять по ТСР, слать POST и GET запросы другим девайсам без ОС - ответ да возможно и это не очень сложно.

[tgruzd 11]

3 минуты назад, smart_pic сказал:

Всего то нужно научиться писать неблокирующие программы для кооперативной ОС, грамотно пользоваться прерываниями и аппаратными возможностями МК и тогда будет легко писать как для 8-ми битников , так и моделей покруче.

Вот это поворот) Спасибо, когда-нибудь попробуем научиться всему этому, раз это сулит возможность программировать "как для 8-ми битников , так и моделей покруче". 

11 минут назад, smart_pic сказал:

без ОС - ответ да возможно и это не очень сложно.

Главные вопросы в такой ситуации: "на..я?" и "зачем?" если всё-таки проще с ОС.    

[Forger 24]

50 minutes ago, tgruzd said:

Ровно это и означает: сломанную ФС трудно не заметить

Это не так, если не проверять ее целостность утилитами. Вы не заметите разницы - с поврежденной FAT по прежнему можно работать (кроме повреждений нулевого MBR сектора).

Если не успели записать часть сектора в FAT, она не разрушается в ноль, как может показаться.

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

 

52 minutes ago, tgruzd said:

Использование f_sync, напротив, принудительно сливает данные на диск не освобождая FILE, что позволяет не открывать (f_open) файл повторно.

Минимальный кэш для самой простой файловой системы - один сектор. Смена сектора на другой принудительно записывает текущий сектор на диск. По сути это и есть своеобразный кэш или по-другому: буфер записи/чтения )

Если хотите быстрее износить флэш диска, то вызывайте f_sync как можно чаще ))

 

52 minutes ago, tgruzd said:

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

Кэширование не может влиять негативно на файловую систему. Позитивно - да: рост скорости работы и сокращение износа флэши диска.

Подозреваю, что вы не конца понимаете что такое кэширование :)

[tgruzd 11]

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

Вы не заметите разницы

 

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

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

В моей ситуации, данные писались постоянно в несколько файлов. Так что "не заметить" всё таки трудновато было.

 

4 минуты назад, Forger сказал:

Если хотите быстрее износить флэш диска, то вызывайте f_sync как можно чаще ))

Спасибо, как раз на износ мне было плевать. В приоритете была целостность файлов при минимизации влияния на скорость записи.

 

25 минут назад, Forger сказал:

Минимальный кэш для самой простой файловой системы - один сектор. Смена сектора на другой принудительно записывает текущий сектор на диск. По сути это и есть своеобразный кэш или по-другому: буфер записи/чтения )

Да уж, теперь-то понял. 

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

Кэширование не может влиять негативно на файловую систему. Позитивно - да: рост скорости работы и сокращение износа флэши диска.

Подозреваю, что вы не конца понимаете что такое кэширование :)

Наверное вы сейчас наспех прочитали про f_sync, толком не поняв, как и зачем я его использовал. Жаль, что вы увидели лишь повод подозревать и смеяться. Не туда подозреваете, похоже.

[Forger 24]

33 minutes ago, tgruzd said:

Спасибо, как раз на износ мне было плевать.

А вот это как раз напрасно! Износ в данном контексте означает рост риска необратимого сбоя системы пропорционально как раз числу вызовов f_sync/f_close файлов, открытых на запись (если конечно речь о самой обычной флэш памяти без внутреннего контроля за износом секторов).

Особенно, если изделие необслуживаемое и флэшка впаяна в плату.

Целостность файлов достигается разными способами.

Вот варианты:

• разбивать большие файлы на мелкие еще на этапе их создания (логи, журналы),
• выполнять заполнение файлов не линейно - например, четные записи писать в файл 1, а нечетные - в файл 2,
• поддерживать контрольные суммы файлов, хэши или т.п..
• схемотехнически обеспечить контроль за провалом питания (аппаратно), чтобы успеть аварийно закончить запись кэшей (самое эффективное решение, кстати).

 

 

33 minutes ago, tgruzd said:

 

Наверное вы сейчас наспех прочитали про f_sync, толком не поняв, как и зачем я его использовал.

Ошибаетесь, мне прекрасно знаком такой сценарий работы журнала логов и что такое f_sync. Не стоит поверхностно судить 😉 

Проблема в том, что при использовании f_sync пропорционально растет риск потери данных при неожиданном пропадании питания. Т.е. чем чаще пишем на диск, тем выше вероятность сбоя. Уточню иначе: растет вероятность совпадения момента отключения питания с моментом записи.

Диск в режиме "только для чтения" имеет нулевой риск повреждения FAT.

Как раз в надежно работающем изделие очень важно минимизировать запись (точнее стирание секторов/блоком) на диск на базе флэш-памяти.

 

[turnon 1]

44 minutes ago, Forger said:

Целостность файлов достигается разными способами.

Вот варианты:

• разбивать большие файлы на мелкие еще на этапе их создания (логи, журналы),
• выполнять заполнение файлов не линейно - например, четные записи писать в файл 1, а нечетные - в файл 2,
• поддерживать контрольные суммы файлов, хэши или т.п..

Вот именно из-за этого я и перешел на кольцевой буфер в NOR, в котором надежность гарантируется "by design", вместо всех этих мер для повышения надежности файловой системы. Которые в итоге из-за сложности и невозможности 100% покрытия тестами эту надежность в конечном итоге так и не смогут обеспечить.
 

On 12/6/2022 at 7:51 AM, Solonovatiy said:

Я писал в ТДД на JS и пробовал писать на СИ. Вот по моему мнению, TDD это то, что лезет в СИ из яваскрипта, не взирая на специфику. 
ТДД по замыслу его авторов и евангелистов подразумевает работу циклами редактирование-отладка по 2-3 минуты. (некоторые в десятках секунд вообще меряют).

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

Да и в рабочем коде никто не заставляет начинать с написания теста. Но после реализации функциональности - покрыть этом тестом.
 

8 hours ago, Forger said:

Я использовал coreJSON, есть на гитхабе. Использовал его только для чтения json настроек.

О, не знал про такую. Реализация выглядит цельнее и строже, надо опробовать вместо mjson.
 

On 12/6/2022 at 7:51 AM, Solonovatiy said:

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

Что же такое с СИ что это более ресурсоемкая задача? Не вижу проблем. Более того, строгая типизация сразу отсеивает 50% ошибок на этапе компиляции, по сравнению с тем же яваскриптом, где в тестах много всего проверяется из-за отсутствия этой самой типизации.

[turnon 1]

On 12/6/2022 at 7:51 AM, Solonovatiy said:

У меня проект на С собирается от 30-40 секунд до нескольких минут. (И нет не по причине того, что он все объектники пересобирает, а по причине линковки). Я видал проект, где тесты пересобирались около 7 минут.

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

[tgruzd 11]

21 минуту назад, Forger сказал:

Ошибаетесь, мне прекрасно знаком такой сценарий работы журнала логов и что такое f_sync. Не стоит поверхностно судить

Вы первый начали.  Если бы внимательно прочитали про сценарий в котором я использовал f_sync, то поняли бы, что это почти не влияло на частоту записей. 

20 минут назад, Forger сказал:

Целостность файлов достигается разными способами.

Вот варианты:

Да кто же спорит про разные способы?  Вот, это видимо, писали люди, не разбирающиеся в ФС, раз советуют что-то из вне вашего списка: 

27 минут назад, Forger сказал:

если конечно речь о самой обычной флэш памяти без внутреннего контроля за износом секторов

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

много мелких записей писать на SD

Я тут даже комментировать не стану.

 

 

[turnon 1]

On 12/6/2022 at 7:51 AM, Solonovatiy said:

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

Не ужаснее самого кода ). Ясное дело, тесты это тоже код, который тоже приходится рефакторить и т.д. Это нормально.

Начинал писть тесты с фреймворка для СИ CuTest, неудобно тем что надо вручную регистрировать тесты. Потом перешел на C++ и cpputest, намного приятнее по сравнению с CuTest. Cейчас на googletest, еще удобнее. Ну и понятное дело тестовый проект - это консольное приложение, исполняется на большом ПК.

[Forger 24]

40 minutes ago, tgruzd said:

Вот, это видимо, писали люди, не разбирающиеся в ФС, раз советуют что-то из вне вашего списка: 

Очевидно, что вы не до конца понимаете как происходит запись в железе, внутри файловой системы и в итоге смешали мух с котлетами. Поясню: есть запись данных, а есть еще запись внутрь FAT таблицы. Это две РАЗНЫЕ записи и они ОБЕ вызываются в f_sync по очередно.

А будет ли при этом реально перезаписываться соотв. сектора в FAT или области данных диска - это уже зависит от реализации файловой системы и ее кэшей.

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

 

40 minutes ago, tgruzd said:

то поняли бы, что это почти не влияло на частоту записей. 

дело хозяйское, я указал на нюансы, что тут не все так просто, как кажется. По мне применение f_sync - это некий "костыль", имеющий свои "подводные камни"

 

[tgruzd 11]

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

вы не до конца понимаете

У вас эта мысль прямо красной линией в каждом сообщении. Ок, я не до конца понимаю, если вы так настаиваете. Если вас задел мой первоначальный вопрос о влиянии вашего кэширования на ваши данные, прошу меня простить: уверен, вы всё делали правильно. Я просто описал (возможно невнятно и чрезмерно кратко, ещё раз извините) свой случай, где кэширование, будь оно только на уровне ФС, принесло бы не только пользу но и вред.

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

Это две РАЗНЫЕ записи и они ОБЕ вызываются в f_sync по очередно.

Да, именно  это мне и нужно было, при том, чтобы ещё и формат файла не ломался, так как при последующем включении после сбоя желательно было писать в тот же файл. Ещё раз повторю, на всякий случай: в моём случае f_sync почти не увеличивал частоту  "реальной" записи. Хотя, уже сомневаюсь что вы это поймёте (имею в виду не вашу способность, а моё нежелание описывать в подробностях своё решение и соображения при его реализации).

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

дело хозяйское, я указал на нюансы, что тут не все так просто, как кажется. По мне применение f_sync - это некий "костыль", имеющий свои "подводные камни"

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

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

следует с осторожностью относится к таких картинкам, проповедующим не самые лучшие решения особенно для встраиваемых устройств.

 

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

На этом предлагаю завершить нашу с Вами дискуссию.

Изменено 10 декабря, 2022 пользователем tgruzd

[Forger 24]

10 minutes ago, tgruzd said:

которые дают люди не разобравшись в вопросе

Невозможно разобраться в вопросе, если он звучит абстрактно и неконкретно.

11 minutes ago, tgruzd said:

но с порога орущие: "вы всё делаете неправильно".

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

12 minutes ago, tgruzd said:

Да, именно  это мне и нужно было, при том, чтобы ещё и формат файла не ломался,

если сбой произошел во время записи данных о файле в FAT, то пострадает некоторая область FAT (записи о файлах, каталогах), а не только файл или некий "формат файла", 

кстати, что подразумевается под этом вашим новым термином: сломался "формат файла"?

 

12 minutes ago, tgruzd said:

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

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