[mantech 34]

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

Это обычная проблема в "прослойке между стулом и клавиатурой".

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

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

Изменено 19 октября, 2020 пользователем mantech

[turnon 1]

17 minutes ago, mantech said:

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

 

Тут скорее важна не сохранность, а целостность ФС. Аппаратные средства имеется в виду резервное питание? Но это не спасет от непредвиденного ресета МК.

[mantech 34]

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

Аппаратные средства имеется в виду резервное питание? Но это не спасет от непредвиденного ресета МК.

Да, небольшой ионистор или кондер.  Непредвиденный ресет МК может быть только по 2м причинам - 1) неправильная разводка ПП или плохое питание, 2) кривость программиста. В обоих случаях никакая ФС не спасет.

[turnon 1]

3 minutes ago, mantech said:

Да, небольшой ионистор или кондер.  Непредвиденный ресет МК может быть только по 2м причинам - 1) неправильная разводка ПП или плохое питание, 2) кривость программиста. В обоих случаях никакая ФС не спасет.

Срабатывание вочдога, мощная помеха - кривизна рук тут ни при чем, программ без багов не бывает.

[jcxz 184]

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

Можно-то можно, но не факт, и это написание "с нуля" какого-то своего поделья, абсолютно нестандартного.

Если эта ФС не идёт наружу устройства, то на кой нужен какой-то "стандарт"? Главное чтобы оно было оптимально выполняемой задаче.

Да и стандартное - тоже можно реализовать. Только времени больше потратить.

Цитата

Мне больше нравится что-то стандартное.

Мне больше нравится программировать DSP, но давно их не использовал, ибо для решаемых задач оптимальнее Cortex. Личные пристрастия - не лучший советчик в разработке.  

Цитата

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

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

48 минут назад, turnon сказал:

Тут скорее важна не сохранность, а целостность ФС. Аппаратные средства имеется в виду резервное питание? Но это не спасет от непредвиденного ресета МК.

Вы таки реально не знаете или просто троллите? 

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

А главный принцип чтобы не было потерь: никогда не писать поверх. Если ему следовать - никаких ионисторов и пр. хлама не нужно.

[turnon 1]

1 hour ago, jcxz said:

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

А главный принцип чтобы не было потерь: никогда не писать поверх. Если ему следовать - никаких ионисторов и пр. хлама не нужно.

Если так все просто, почему нет чего-то типа jffs, но не жрущего 128K памяти? Если для вас просто - изложите пожалуйста подробно алгоритм или дайте ссылку на реализацию. Это будет прорыв. LittleFS, jffs и прочее - поудаяют репозитории с гитхаба или где оно там лежит.

[mantech 34]

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

Почитайте что-нить например про "журналирующие ФС". Всё давно придумано.

Если честно, не видал ФС, которые при внезапном откл. питания, при записи, работают без сбоев. И еще одно . есть планшены на андроиде, там линукс и вроде, как ext3 или 4 не помню. Так вот почему-то при тестировании на откл. питания, через некоторое время все они перестали корректно загружаться. На сколь помню, ext - журналируемая ФС. Объясните сей феномен? Мне интересно...

[jcxz 184]

15 минут назад, turnon сказал:

Если так все просто, почему нет чего-то типа jffs, но не жрущего 128K памяти?

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

Так напишите, выложите в общий доступ и будет.  

15 минут назад, turnon сказал:

Если для вас просто - изложите пожалуйста подробно алгоритм или дайте ссылку на реализацию.

Видимо Вы - один из тех, кого в гугле забанили? Одна из первых ссылок:

https://books.google.lv/books?id=eGGLDwAAQBAJ&pg=PA335&lpg=PA335&dq=журналирующая+запись&source=bl&ots=skVbtVU7i1&sig=ACfU3U3UWZPsQsPlPeaZ0u0sqUqXJn1wjQ&hl=ru&sa=X&ved=2ahUKEwjp7PLhscDsAhVmoosKHY4CDlQQ6AEwCHoECAkQAg#v=onepage&q=журналирующая запись&f=false

В начале стр.335 совершенно полно описан алгоритм работы журналирующей ФС.

 

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

[mantech 34]

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

Срабатывание вочдога, мощная помеха

У вас устройство в космосе работает, без радзащиты? Или в трансформаторной подстанции? Во всех остальных случаях, если это не форс-мажор, вроде ядерного взрыва неподалеку или удара молнии, при условии, что соблюдены все правила защиты от выбросов по питанию и входным-выходным портам, никаких помех для работы МК быть не должно...

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

никогда не писать поверх

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

Изменено 19 октября, 2020 пользователем mantech

[jcxz 184]

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

Если честно, не видал ФС, которые при внезапном откл. питания, при записи, работают без сбоев.

Ну да - видимо врут всё про журналирующие ФС. Это видимо такой всемирный заговор и их на самом деле не существует.

 

PS: Гадать - что там в чёрном ящике и обсуждать конспирологические теории - нет никакого желания. Имеющий голову - да поймёт. Приведённой информации более чем достаточно. 

[mantech 34]

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

Ну да - видимо врут всё про журналирующие ФС. Это видимо такой всемирный заговор и их на самом деле не существует.

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

[jcxz 184]

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

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

Я уже привёл ссылку где подробно разжёван алгоритм работы: "Все операции которые нужно выполнить, предварительно записываются в журнал (в том числе и модификации FAT); потом эти операции выполняются; потом эта запись журнала удаляется".

При старте ПО (старте ядра ФС), считывается журнал, и если там есть неудалённая запись - она выполняется. Потом удаляется. Если сбой питания произойдёт во время этой операции - она будет повторена заново при след. старте ПО. И будет повторятся пока не выполнится полностью.

Всё.

Журнал - это простой кольцевой буфер. "Удаление записи журнала" - это естественно не стирание её, а запись в неё флага "удалена" (либо запись след. записи журнала означающей "журнал пуст"). Всё просто как 2*2.  

Это в общем случае. В конкретных случаях возможны вариации, упрощения.

[turnon 1]

59 minutes ago, jcxz said:

Я уже привёл ссылку где подробно разжёван алгоритм работы: "Все операции которые нужно выполнить, предварительно записываются в журнал (в том числе и модификации FAT); потом эти операции выполняются; потом эта запись журнала удаляется".

Выглядит действительно просто. Можно в FatFS в disk_write все сначала писать в журнал, а затем уже с журнала перенос на реальный носитель. Журнал сделать размером сектора (512 байт), если в disk_write приходит на запись больше одного сектора - последовательно писать сначала в журнал. затем на носитель. Журнал размером 512 байт храним на том же носителе.

Почему же нет реализаций открытых, если все так просто?

[aaarrr 63]

58 minutes ago, turnon said:

Почему же нет реализаций открытых, если все так просто?

Потому что все не так просто. Попробуйте объяснить, чем и как поможет озвученный механизм "журналирования".

[mantech 34]

9 минут назад, aaarrr сказал:

Потому что все не так просто. Попробуйте объяснить, чем и как поможет озвученный механизм "журналирования".

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