Переключение ФС QNX6 в режим R/O

[GrayCat]

Приветствую!

Используем QNX 6.5.0 (+SP1). На дисках - файловая система QNX6.

И столкнулись с ситуацией: в какие-то произвольные моменты времени, вдруг, система перестаёт записывать на диск. При этом всё остальное работает, наши программы крутятся. Когда-то, ещё во времена QNX 6.2.0, мы старались писать наши программы так, чтобы ошибки дисков (предположительно, одиночные) не приводили к падению сервера. Соответственно, ошибки записи файлов просто игнорировались. И сейчас это нам вылезло боком. Тихонько, без предупреждения, перестают писаться логи.  Причём, после одной-двух перезагрузок всё восстанавливается! Пишет, как ни в чём не бывало! Естественно, теперь-то мы сделаем  соответствующую проверку и аварийный останов, но проблема-то остаётся.

Отсюда вопрос: кто с таким сталкивался? От чего может файловая система уходить в режим "только чтение"?  Как это предотвратить?

[Антон Падалко]

Приветствую!
Мы тоже периодически сталкиваемся с такой ситуацией, происходит и на чистом QNX6.5.0 и на QNX6.5.0SP1.
В нашей системе применяется два диска SSD (с него грузится система) + HDD (на него пишутся архивы и логи).
Также в произвольные моменты времени перестает работать запись на диск, и на SDD, и на HDD.
При этом машина работает - все наши программы сбора данных с различных датчиков работают, информация передается по tcp на другие машины, интерфейс (на Qt) живой.
Но в эти моменты становится невозможно удаленно подключиться к машине: telnet, ssh, phrelay, phditto, qnet - ничего не работает.
Установленные ранее сетевые tcp соединения (передача данных на другие машины) остаются работать до первого дисконнекта, после чего уже не восстанавливаются.
При попытке соединится с этой машиной по Qnet все утилиты вешаются (Blocked) на REPLY к её менеджеру процессов procnto.
Пробовали подключать расшаренную папку Windows машины и писать логи туда - результата нет, запись по сети (на SMB) также прекращается вместе с записью на диск.
После перезагрузки машины никаких проблем нет, всё работает до следующего раза.
Периодичность проявления разная, на каких-то машинах чаще (раз в несколько месяцев), на других раз в год, на третьих вообще ни разу не было проблемы.

[GrayCat]

Но в эти моменты становится невозможно удаленно подключиться к машине: telnet, ssh, phrelay, phditto, qnet - ничего не работает.

Да-да-да, и это тоже! Мы сначала не могли понять, почему не можем на свои удалённые машины зайти - неужели кто-то полазил и пароли поменял!? Притом что после перезагрузки доступ восстанавливается.

Но потом сопоставили моменты глюков: да, "R/O" и отказ в доступе - это одна и та же беда. Ну, можно понять, SSHD пытается записать на диск ".lastlogin" и обламывается...

Вопрос всё более актуален: От чего это происходит, и как это предотвратить?

[Владимир Махилёв]

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

[GrayCat]

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

Э-мм...     И как вы себе представляете отладку экспериментального софта на "боевых" удалённых машинах? На которые, в случае сбоя, даже невозможно по сети зайти? И где местный персонал даже по телефонным командам не в состоянии переключить задачи по Alt+Tab ?

У вас хотя бы есть предположения, от чего этот Read-Only происходит?

Вот у нас, например, такая версия: на мат. платах Advantech AIMB-742 есть такое свойство, что иногда при загрузке они теряют половину RAM. Стоит DIMM на 1 GB, а при загрузке видится 512 MB. Жмякнешь Reset - всё снова в порядке. В принципе, нашему софту для работы и полгига хватает, но иногда, например, при загрузке большого файла журнала, может резко потребоваться дополнительные несколько десятков/сотен МБ. Или, как вариант, демон базы данных QDB непредсказуемо "проголодается". И, возможно, это тем или иным образом ввергает файловую систему в хаос и она переходит в R/O.

Мы попробуем у себя это дело как-то сымитировать. Без стабильного повторения глюка, лечить его смысла нет.

[Владимир Махилёв]

Э-мм...     И как вы себе представляете отладку экспериментального софта на "боевых" удалённых машинах? На которые, в случае сбоя, даже невозможно по сети зайти? И где местный персонал даже по телефонным командам не в состоянии переключить задачи по Alt+Tab ?

У вас хотя бы есть предположения, от чего этот Read-Only происходит?

Вот у нас, например, такая версия: на мат. платах Advantech AIMB-742 есть такое свойство, что иногда при загрузке они теряют половину RAM. Стоит DIMM на 1 GB, а при загрузке видится 512 MB. Жмякнешь Reset - всё снова в порядке. В принципе, нашему софту для работы и полгига хватает, но иногда, например, при загрузке большого файла журнала, может резко потребоваться дополнительные несколько десятков/сотен МБ. Или, как вариант, демон базы данных QDB непредсказуемо "проголодается". И, возможно, это тем или иным образом ввергает файловую систему в хаос и она переходит в R/O.

Мы попробуем у себя это дело как-то сымитировать. Без стабильного повторения глюка, лечить его смысла нет.

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

Полагаю, что для начала стоит разобраться с проблемой с определением памяти - это явно ненормальное поведение. Хотя на мой взгляд крайне маловероятно, что причина проблемы работы с диском как-то связана с этим.

С похожими проблемами (переход файловой системы в read-only) к нам периодически обращаются, но информации для отладки и решения катастрофически недостаточно. Поэтому мы сейчас пытаемся повторить и отладить эту ошибку локально.

[GrayCat]

Хмм...       

Проблема уже "давит". На нескольких филиалах уже словили эту бяку