Страниц: 1 [2] 3
  Печать  
Автор Тема: Отработка аварийного отключения питания в QNX 6.4.1  (Прочитано 14722 раз)
aluv
Sr. Member
****
Offline Offline

Сообщений: 301


Просмотр профиля
« Ответ #15 : Августа 09, 2011, 11:27:35 pm »

Тоесть, если запустить
deb-eide blk delwri=0
то кеширования записи не будет.

Когда мне нужно было отключить кэш диска, я писал так:
deb-eide blk cache=0

Но наверное для драйвера это одно и тоже.
Записан
vshemm
Sr. Member
****
Offline Offline

Сообщений: 317


Просмотр профиля
« Ответ #16 : Августа 09, 2011, 11:55:35 pm »

Подскажите пожалуйста, имеются ли в QNX 6.4.1 собственные средства (API, утилиты) для отработки ситуации неожиданного отключения питания?
Чтобы сбросить кэши на диск, завершить процессы и т.д.
К примеру, аппаратура может выставить соответствующее прерывание, и у системы будут какие-то микросекунды для отработки безопасного завершения работы.

Нет.

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

Разовью свою мысль. Есть сигнал по пропаданию питания (прерывание), и есть некоторое время, за которое некоторые
системы (hardware) смогут выполнять свои функции. Естественно, это время не задано жестко. Оно меняется от многих
факторов, например: температура, ревизия микросхем, предыдущее состояние системы перед сбоем, причина сбоя, и т.д.
Только уже поэтому забавно наблюдать дискусс на форуме по qnx в данном направлении, ибо это чуждо даже самому
извращенному понятию real time.

Идем дальше. Предположим, у нас есть гарантированных 10мс времени, в течении которых все железо работает в штатном
режиме (опять же, если оно задано, есть нечто вроде UPS, значит смысла начальный вопрос не имеет - что 10мс сделать,
что минуту одинаково).

Из прерывания сбросить всё на диски невозможно, это очевидно. Засинхронизировать все состояния программ тоже. Синхронная
запись без кеширования тоже ничего не даст.

Из менеджера, который запустится по прерыванию, как предложил oder, sync() сделать можно, но это не решит проблему.
Действительно, sync() отработает и вернется, но если кто-то еще в этот момент захочет сделать запись, все накроется.
Следовательно, менеджер должен работать синхронно со всеми прикладными программами.

Но и это еще не все. Предположим, идет write. Драйвер, работающий с железом ожидает готовности аппаратуры. Тут питание
пропадает, запускается наш "монитор" и что? Он, во-первых должен знать про write(), во-вторых, он должен либо отменить
этот write, либо дождаться его завершения, что в условиях ограничения в 10мс просто смешно (без переписывания драйвера
диска).

И т.д.

Короче, при таком подходе мы наблюдаем возникновение связей между почти всеми подсистемами, что в общем случае не решаемо.
Записан
Evgeniy52
Jr. Member
**
Offline Offline

Сообщений: 55


Просмотр профиля
« Ответ #17 : Августа 10, 2011, 11:44:39 am »


А, по моему, вполне даже очевидно:
Спасибо, увидел.

Если открывать файлы по open(..., O_DSYNC, ...),
а если что-то вроде
# some_program > log.txt
Huh?

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

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

Записан
oder
Гость
« Ответ #18 : Августа 10, 2011, 12:25:19 pm »

Если открывать файлы по open(..., O_DSYNC, ...),
а если что-то вроде
# some_program > log.txt
Huh?
Все равно, write пишет данные только в драйвер файловой системы, который живёт в ОЗУ. А на физический носитель блоки сбрасываются асинхронно через io-blk.so, и write этого не ждёт кроме случаев открытия файла с O_DSYNC.
И не забывайте, что приоритетов никто не отменял. Если ваша нить работает на высшем приорите, по сравнению с devb-eide, в первую очередь система будет обслуживать её, а уж потом запись кластера в io-blk.
Записан
PoP
Sr. Member
****
Offline Offline

Сообщений: 336


Просмотр профиля
« Ответ #19 : Августа 10, 2011, 12:56:53 pm »

Видимо наиболее стандартным будет SIGPWR всем, кто его поймёт (при этом, скорее всего, и sync() файловая система сделает сама). А дальше уж пусть каждый спасает критические данные, отключает оборудование или тихо уходит в никуда, чтоб другим не мешать.
Записан
mike
QOR.Moderator
*****
Offline Offline

Сообщений: 1186


Welcome to Lunatic Asylum.


Просмотр профиля WWW
« Ответ #20 : Августа 11, 2011, 03:04:31 pm »

Или сигнал уже есть?
Да, есть универсальные проц. платы на которых выход PFO (power-fail output) подключен к линии прерываний.
подумалось тут, вы не правильно интерпретируете этот сигнал и пытаетесь неправильно его обработать
этот сигнал означает что питание опустилось ниже критического уровня, но это ещё не значит что всё совсем плохо, по этому сигналу нужно делать извещение оператору что что-то не так с питанием
а если питание действительно рубанётся, ничего сделать вы уже не успейте
кстати пример из жизни
Цитировать
#sh ver | i Model number: 
Model number: WS-C2950-24
#sh env power
Internal POWER supply is FAULTY
так он уже не первый год работает, заменить пока не на что Sad, периодически OK бывает Smiley
Записан
Basil-64
Sr. Member
****
Offline Offline

Сообщений: 282



Просмотр профиля
« Ответ #21 : Августа 12, 2011, 09:44:26 am »

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

В жизни всегда есть место подвигу - главное быть подальше от этого места. Но никак не получается.
mike
QOR.Moderator
*****
Offline Offline

Сообщений: 1186


Welcome to Lunatic Asylum.


Просмотр профиля WWW
« Ответ #22 : Августа 12, 2011, 10:01:16 am »

для любых систем ИБП нужен, а для серьёзных простеньким не обойтись, по минимуму он управляемый должен быть
Записан
Evgeniy52
Jr. Member
**
Offline Offline

Сообщений: 55


Просмотр профиля
« Ответ #23 : Августа 12, 2011, 10:16:41 am »

Естественно, ИБП будет. Управляемый.
Кстати, не подскажете ли примеры ИБП с возможностью как программного, так и хардварного (вывод, на который можно подать сигнал и он отрубится) управления?

Но в системе возможны ситуации именно аварийного отключения ИБП, по наступлению определенного события.
Записан
Basil-64
Sr. Member
****
Offline Offline

Сообщений: 282



Просмотр профиля
« Ответ #24 : Августа 14, 2011, 12:17:25 pm »

Но в системе возможны ситуации именно аварийного отключения ИБП, по наступлению определенного события.
Определенное это, извиняюсь, какое?  Взрыв фугаса в батарее? Ежели нет, так упс успеет проорать о своем предстоящем отключении и времени на корректное сворачивание системы у вас будет уйма.
Записан

В жизни всегда есть место подвигу - главное быть подальше от этого места. Но никак не получается.
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #25 : Августа 14, 2011, 02:47:38 pm »

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

По поводу UPS. Мы традиционно используем стоечные APC.
У них есть порт EPO, позволяет вырубать UPS по красной кнопке или по сигналу со щита. Не пробовали, не знаю настраивается ли там отложенное отключение или оно всегда мгновенное. По управляющему порту время отключения можно задать любое.

Программное управление (включение/выключение, запрос состояния) возможно по COM, USB и по Ethernet.
Для последнего используется специальная плата, вставляемая в SMARTSlot: http://www.apc.com/products/family/index.cfm?id=98
У них только RJ45, оптики нет.

У нас запитка идет с двух фидеров, через ATS (Automated Transfer Switch, тоже от APC), поэтому управление UPS сделано по Ethernet.
Мне показалось, что включать UPS проще именно через платку по Ethernet. К тому же она дает SNMP и веб-интерфейс.

« Последнее редактирование: Августа 14, 2011, 02:49:13 pm от dmi » Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #26 : Августа 14, 2011, 02:57:30 pm »

Но в системе возможны ситуации именно аварийного отключения ИБП, по наступлению определенного события.
Определенное это, извиняюсь, какое?  Взрыв фугаса в батарее? Ежели нет, так упс успеет проорать о своем предстоящем отключении и времени на корректное сворачивание системы у вас будет уйма.
Аварийное отключение питания при срабатывании пожарной тревоги например. Если на сервера водичка польется, UPSы пользы не принесут Smiley
Записан
aluv
Sr. Member
****
Offline Offline

Сообщений: 301


Просмотр профиля
« Ответ #27 : Августа 16, 2011, 01:53:28 pm »

Или сигнал уже есть?
Да, есть универсальные проц. платы на которых выход PFO (power-fail output) подключен к линии прерываний.
подумалось тут, вы не правильно интерпретируете этот сигнал и пытаетесь неправильно его обработать
этот сигнал означает что питание опустилось ниже критического уровня, но это ещё не значит что всё совсем плохо, по этому сигналу нужно делать извещение оператору что что-то не так с питанием

Все верно PFO – это только сигнал проседания напряжения ниже допустимого. Он произойдет и когда питание платы отключат и когда питание просядет. К сожалению, такое нередко случается, т.к. и ИП бывают разные и разного качества и про пиковое потребление плат разработчики умалчивают.

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

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

Поэтому по срабатыванию PFO надо сохранить отладочную информацию в энергонезависимую память (свободный банк CMOS, EEPROM, FRAM и т.п.), послать всем уведомление о начале конца (SIGPWR и т.п.), возможно понизив приоритет (дать другим шанс что-то сохранить), программно перезапустить плату (shutdown_system() и т.п.). Наличие взведенного сторожевого таймера обязательно, т.к. это нештатная ситуация и гарантий никаких.

а если питание действительно рубанётся, ничего сделать вы уже не успейте

Да, гарантий никаких, но за несколько миллисекунд можно многое успеть (например послать критические команды на остановку приводов) и попробовать стоит.
Записан
aluv
Sr. Member
****
Offline Offline

Сообщений: 301


Просмотр профиля
« Ответ #28 : Августа 16, 2011, 01:54:54 pm »

С другой стороны были случаи, когда проблемы с ИП и проц. платами проявлялись через несколько лет с наступлением лета. Может PFO там срабатывало и раньше (но не обрабатывались), но реальные "глюки" проявились позже. ИП поменяли.

Т.е. конечно можно просто просигналить оператору, что что-то не так и положиться на сторожевой таймер. Но т.к. множество факторов просто крайне затруднительно отследить и даже предугадать (повышение потребления, перегрев, снижение скорости реакции и т.п.), то лучше по срабатыванию PFO принудительно перезапускать плату.
Записан
mike
QOR.Moderator
*****
Offline Offline

Сообщений: 1186


Welcome to Lunatic Asylum.


Просмотр профиля WWW
« Ответ #29 : Августа 16, 2011, 01:59:05 pm »

можно ещё попробовать реализовать режим низкого энергопотребления, правда хз как это сделать под qnx красиво
Записан
Страниц: 1 [2] 3
  Печать  
 
Перейти в: