ru.algorithms

 
 - RU.ALGORITHMS ----------------------------------------------------------------
 From : Vitaly Polikarpov                    2:461/132      03 May 2003  17:41:00
 To : Roman Pokrovskij
 Subject : Re: Журналирование
 -------------------------------------------------------------------------------- 
 

 
 02 May 03 20:31, Roman Pokrovskij -> Vitaly Polikarpov:
 
 >> Встраиваемые MCU нередко задействованны в системах управления (в тч и
 >> реал-таймовых), и для них зачастую важны не только восстановление
 >> контекста выч.процесса, но и компенсация отклонения состояния объекта
 >> управления от заданного профиля за recovery time, c учетом предистории
 >> объекта, нередко (например, для исключения потери управляемости объектом)
 >> по совершенно иным критериям управления.
  RP> Это кажется мне двумя разными задачами.  Восстановить контекст (данные) 
  RP> и установив состояние объекта, подправить контекст так чтобы не потерять
  RP> управляемость.
 
 В большинстве случаев embedded MCU лишены многозадачных RTOS - обработка
 событий идет по (не)маскируемым прерываниям в соответствии с приоритетами 
 отработки при ограниченных вычислительных ресурсах. При этом, если
 журналирование выполняет лишь ф-ии логинга событий, а не предистории 
 состояния объкта при потоковых алгоритмах управлении, ним, до 
 восстановления основного процесса, в критических ситуациях лучше пренебечь, 
 чем устраивать реинкарнацию объекта.
 
 При использовании Ж. в управлении, recovery time стараются свести
 (чаще, аппаратно) к максимально допустимому времени реакции на критичные 
 прерывания, ведь оно обычно на порядок меньше, чем у систем с RTOS при 
 довольно скромных ресурсах.
 
 >> RP> Можно поискать в Интернете на тему Crash recovery.
 >> RP> Алгоритм ARIES
 >> Можно, но эти кейворды "в большом почете" совсем по другим темам ;)
  RP> В смысле ? 
 
 Вывалит от репайра HDD и до элементов коммутации одноименной фирмы.
 
  RP> Если сам алогоритм совсем не в тему, то я прошу прощения, я
  RP> думал что он хоть чуть-чуть в тему. 
 
 В тему, как и многое другое, типа контроля целостности, помехоустойчивого 
 кодирования данных, когда речь идет о устойчивости к внешним воздействиям. 
 Как-то поднимал в su.dbms вопрос о верификации хранимого контента средствами
 нынешних СУБД, но иного кроме "нет пророка кроме транзакции, и бэкап ее 
 пророк" и промСУБД, типа Оракла, ничего в ответ не услышал - бессбойность 
 "железа" возведена в ранг постулата, хотя ним является лишь в первом 
 приближении и тепличных условиях.
 
  RP> Если о том, что я слишком краток то я просто боюсь ужать 20 страниц в
  RP> нечитабельную кашу.  
 
 в 92-97 БД админил..
 
  RP> Вот опишу просто требуемую инфраструктуру.
  RP> А ты доходчиво расскажи, почему она не применима в embdded. 
  RP> Т.е. что она в чистом виде не применима понятно, но во-первых можно и
  RP> видоизменять, а во-вторых мне будет полезно в терминах embded это 
  RP> услышать.
 
 Они как и нюансы бэкапа обычно application specific.
 
  RP> Я же пока буду в терминах DB, если можно ... иначе запутаюсь.
  RP> Есть два типа памяти - защищенная (от crash'ей) и не защищенная (ОЗУ).
 
 Энергонерависимая память данных, защищенная от изменений супервизором
 напряжения питания при невалидном питании. Обмен с ней (flash) обычно блочный, 
 число блоков/кристалл  8..2048. Ресурс по числу циклов перезаписи ограничен -
 для эффективного его использования уместна кольцевая организация накопителя.
 
  RP> Есть база данных,
  RP> она же набор страничек в защищенной памяти. Есть
  RP> механизм переноса странички из защищенной памяти в основную 
  RP> и есть обратный механизм сохранения странички в защищенную.
 
 Буфферирование r/w флеша можно делать (MCU+RAM) софтверно, но надежней и 
 проще использовать флеш большого объема, у которых имеется встроенное 2-х
 буферное ОЗУ на размер блока, обмен с которым у MCU квитируется.
 
 Отсутствие вероятности дробления потока команд при сбоях и единственность
 потока логинга позволяют ограничится лишь хранимым при рестарте указателем на
 хвост лога, или связным списком, если время отката не критично.
 
 [Шкаф поставили на попа, поп закричал(c)]
 
  RP> Этой инфраструктуры полностью достаточно что бы база данных смогла
  RP> максимально восстанавиться после любых Crash'ов, в произошедших в любой
  RP> фазе, включая саму процедуру Recovery.
 
 Также послано в RU.EMBEDDED
 
 Vitaly Polikarpov, vitvp[эt]mail.ru
 ---
  * Origin: INTELLECT group (2:461/132)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор