Официальный форум СВД Встраиваемые Системы
15 Декабря, 2018, 13:59:31 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.

Войти
 
 
 Сайт СВД ВС  Начало   Помощь Поиск Войти Регистрация  
Страниц: [1]   Вниз
  Печать  
Автор Тема: Переключение ФС QNX6 в режим R/O  (Прочитано 276 раз)
GrayCat
Пользователь

Сообщений: 23


Embedder


« : 15 Июня, 2018, 17:09:26 »

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

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

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

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

Gray©at
Антон Падалко
Пользователь

Сообщений: 36


« Ответ #1 : 18 Июня, 2018, 09:01:49 »

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

« Последнее редактирование: 18 Июня, 2018, 09:04:45 от Антон Падалко » Записан
GrayCat
Пользователь

Сообщений: 23


Embedder


« Ответ #2 : 18 Июня, 2018, 10:04:43 »

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

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

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

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

Gray©at
Владимир Махилёв
Сотрудник СВД ВС
Ветеран

Сообщений: 682



WWW
« Ответ #3 : 18 Июня, 2018, 16:09:46 »


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

GrayCat
Пользователь

Сообщений: 23


Embedder


« Ответ #4 : 19 Июня, 2018, 09:15:57 »

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

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

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

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

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

Gray©at
Владимир Махилёв
Сотрудник СВД ВС
Ветеран

Сообщений: 682



WWW
« Ответ #5 : 20 Июня, 2018, 17:17:32 »

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

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

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

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


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

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

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

Записан

GrayCat
Пользователь

Сообщений: 23


Embedder


« Ответ #6 : 04 Июля, 2018, 10:26:47 »

Хмм...    Embarrassed   

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

Gray©at
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP © 2002-2018 СВД Встраиваемые Системы.
При использовании материалов сайта ссылка на forum.kpda.ru обязательна.

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines | © Aiwan. Kolobok smiles | Sitemap
Valid XHTML 1.0! Valid CSS!
Сайт СВД ВС

В последний раз google посещал эту страницу 16 Ноября, 2018, 16:20:51