Jump to content

    
Sign in to follow this  
haker_fox

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

Recommended Posts

2 hours ago, iliusmaster said:

Гарантированно "безбажно" можно научить писать всех, вопрос в другом, что редко кто  хочет учиться.  Тяп - ляп и в "продакшен", а сами - хабр окучивать. Такой девиз современных разработчиков.

Какой-то нездоровый оптимизм.  Похоже невнимательно следите за публикациями на хабре.  
А почитайте-ка про Weird machine. Дело в том, что определенными воздействиями любую реальную программу можно заставить работать глючно.
Мне в этом плане понравилась вот эта статья- https://tcipg.org/sites/default/files/papers/2014_q3_tfs1.pdf
Мужики просто манипуляцией прерываниями заставляют контроллер выполнить нужный им код, которого изначально нет в прошивке.
И вычислить анализом кода этот баг невозможно.  

 

 

Share this post


Link to post
Share on other sites

В голос орнул про "надо писать не глючное ПО". Явно троллинг.

По поводу алгоритмов записи. Вот есть интересная запись на хабре: https://habr.com/post/262163/

Мне понравилась идея с маркерами, то есть как отследить, что питание вырубилось в процессе записи данных.

Share this post


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

Мне понравилась идея с маркерами, то есть как отследить, что питание вырубилось в процессе записи данных.

А что сложного? Выделить один байт в заголовке записываемого блока. При записи блока выставить ему значение == значению стёртой ячейки флешь (предположим это 0xFF). После завершения записи блока выполнить запись поверх этого байта со значением != 0xFF (предположим это 0xFE). Теперь при старте ПО проверяем блок:

1) Если все байты блока имеют значение == 0xFF - блок чистый (не писался);

2) Если в блоке есть байты со значением != 0xFF и наш байт == 0xFE - блок записан полностью;

3) Если в блоке есть байты со значением != 0xFF и наш байт == 0xFF - был рестарт в процессе записи блока.

Share this post


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

А что сложного?

В том и беда, что хотелось бы не читать все байты в блоке. А косвенными методами определить, было ли что-то записано в блоке или нет. Двухэтапное маркирование, приведенное в статье, ИМХО, довольно неплохой метод, при этом также очень похожий на Ваш.

Share this post


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

В том и беда, что хотелось бы не читать все байты в блоке. А косвенными методами определить, было ли что-то записано в блоке или нет. Двухэтапное маркирование, приведенное в статье, ИМХО, довольно неплохой метод, при этом также очень похожий на Ваш.

Ну можно изменить мой метод, добавив перед записью блока, запись в тот маркерный байт отдельного значения "старт записи" например == 0xFE, а после завершения записи блока - записывать в этот байт "завершение записи" == 0xFC. Тогда достаточно только этот байт прочитать. Но выигрыш от этого не велик, так как блоки всё равно лучше проверять на валидность при старте ПО (CRC, ...), а значит их нужно читать полностью по любому. А вот при записи 3 шага вместо 2-х - это уменьшение скорости записи. И чтение блока - операция очень быстрая, я в своих устройствах читал их с внешней флешь по dual-SPI на SCLK == 30МГц - время очень малое.

Share this post


Link to post
Share on other sites

Конечно это был троллинг:)))  Несмотря на него никто не отменял грамотного кодирования. При грамотной организации процесса написания кода, он - не глючит и выполняется так, как нужно. Siemens-ы и прочие Philips-ы в примеры приводить не нужно. Для многих их проектов код пишется в китайских и индусских компаниях, зачастую недостаточно качественно. Например, для томографов Philips, между прочим одних из лучших, весь софт управления и визуализации написан в Neosoft (https://www.neusoft.com/about/index.html), почитайте очень крупная компания, где многие гиганты индустрии заказывают.... Лично бывал там, реализуя совместный проект с их медицинским подразделением, и не сказал бы, что там звезды с неба хватают. Таких компаний много, особенно тех, что поменьше. . В России есть некоторые. Потому ссылаться на то, что какие-то ПЛК Siemens глючат - моветон. Программное обеспечение то написано неизвестно кем.

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

А мои проекты все сверхсекретные, спрятаны на флешке, флешка в яйце, яйцо в утке.... ну и далее по тексту. 

Share this post


Link to post
Share on other sites
5 hours ago, iliusmaster said:

И не надо это все в одну кучу складывать.

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

Во-вторых, вы сделали заявление, что

Quote

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

Я понимаю, что это не мне адресовано. Но! Ответить я на это был вправе. Хорошо, отбросим проблемы с ерратами микросхем. Но безбажную прошивку для более-менее сложного объекта написать всё равно проблематично. Хотя бы по причине, указанной iosifk. И вы просто не будете в курсе как правильно расставить эти базовые основные команды для неполностью изученного физического объекта.

Share this post


Link to post
Share on other sites

Попалась как-то в руки книжка от разработчиков NTFS. И там детальное описание механизма отказоустойчивых дисковых операций (перезапись файла, копирование, удаление).

В общих чертах, на примере перезаписи уже существующего файла "File.dat".

1. В журнале делается запись о намерении перезаписать файл "File.dat".

2. В журнал заносится последовательность запланированных операций: записать тело файла на свободное место, изменить FAT1, изменить FAT2, добавить в каталог новую файловую запись "File.dat", пометить прежний файл "File.dat" как удалённый, удалить данные о нём из FAT1, удалить из FAT2. Готово.

3. Операции выполняются одна за другой по плану, при этом каждая отмечается в журнале как начатая, или как завершенная.

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

5. Журнал очищается.

 

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

Журнал ведётся в двух экземплярах, с номерами 0 и 1 - чтобы всегда была копия, на случай отказа системы во время обновления самого журнала.

Share this post


Link to post
Share on other sites
1 hour ago, controller_m30 said:

Попалась как-то в руки книжка от разработчиков NTFS

А не поделитесь?)))) Если в электронном виде доступна...

А за описание алгоритма - спасибо!!!! Интересный подход!

Share this post


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

А за описание алгоритма - спасибо!!!! Интересный подход!

Когда я писал про то, как сделать FatFS устойчивой к сбоям, я имел в виду подобный метод. Вроде в нём нет никакого ноу хау - всё само собой очевидно. Не раз реализовывал системы хранения подобным образом. Главное правило тут: любая небезопасная операция модификации носителя, должна быть журналируемой (перед её началом должна быть сделана в журнале запись о её начале, содержимое и последовательность планируемых операций, в процессе операции в журнале должно бэкапиться всё содержимое перезаписываемых поверх областей, а после завершения - запись удалена). Небезопасные операции модификации - все операции, которые, будучи прерваны, приведут к нарушению логической структуры хранения на носителе. Примерно так.

Share this post


Link to post
Share on other sites
1 hour ago, haker_fox said:

А не поделитесь?)))) Если в электронном виде доступна...

Увы, я читал её ещё в бумажном виде:pardon: 

Книга называется "Хелен Кастер. Основы Windows NT и NTFS", 1996. 

Edited by controller_m30

Share this post


Link to post
Share on other sites

Я бы присмотрелся на вашем месте к SQLite WAL. https://www.sqlite.org/wal.html

Мы активно используем под embedded Linux для задач, с возможной потерей данных (aka. power off)

Share this post


Link to post
Share on other sites
22 minutes ago, psyhologic said:

Мы активно используем под embedded Linux для задач, с возможной потерей данных (aka. power off)

Да все эти потери из-за дешевых SD карт. На хорошей карте вы и FAT замучаетесь убивать. 
 

Share this post


Link to post
Share on other sites
Только что, AlexandrY сказал:

Да все эти потери из-за дешевых SD карт. На хорошей карте вы и FAT замучаетесь убивать. 
 

Целостность данных в файловом представлении в момент выключения питания от качества карты не зависит ровно никак.

Share this post


Link to post
Share on other sites
5 minutes ago, Arlleex said:

Целостность данных в файловом представлении в момент выключения питания от качества карты не зависит ровно никак.

Эт в теории.
А на практике качество карты имеет самое большое значение.
У меня есть карты полность вышедшие из строя или с полностью поврежденной файловой системой. Просто сбоем при записи блока на SD карту вы это не объясните.  

Хотя еще можно подозревать контроллер SDIO, но сама файловая на последнем месте в списке подозреваемых.  

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this