Переключение ФС 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]

Хмм...       

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

[XsanyaX]

Количество RAM ,  похоже,  что непричем. Поймали read-only на машине с 8 GB  оперативной памяти, материнка AIMB-785, проц - Core-i7.  Теперь вообще нет даже подозрений на какие нибудь зависимости. Будем  дальше следить....

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

Вывод утилиты sloginfo c объекта, где один из разделов перешел в read only:

Код:

Dec 26 05:24:58    2    19     0 eide_transfer_downgrade:  UDMA 5 CRC error, path 0, device 0
Dec 26 05:24:59    2    19     0 eide_reset:  complete 302 ms
Dec 26 05:24:59    2    19     0 eide_init_devices: KINGSTON SV300S37A120G path 0, tid 0, udma 2, mdma 2, sdma -1, pio 4, mblk 1
Dec 26 05:25:01    2    19     0 eide_transfer_downgrade:  UDMA 2 CRC error path 0, device 0 (UDMA disabled)
Dec 26 05:25:01    2    19     0 eide_reset:  complete 301 ms
Dec 26 05:25:01    2    19     0 eide_init_devices: KINGSTON SV300S37A120G path 0, tid 0, udma -1, mdma 2, sdma -1, pio 4, mblk 1

Не знаю, поможет ли чем-то эта информация...

[GrayCat]

Вывод утилиты sloginfo c объекта, где один из разделов перешел в read only:

Т.е., получается, после CRC-ошибки в SATA-интерфейсе (вполне рядовое явление), драйвер SATA некорректно переинициализирует контроллер дисков?

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

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

Судя по разобранным нами случаям поломки файловой системы, причины были связаны с аппаратными ошибками работы диска/контроллера и происходило примерно следующее: очень редко возникала аппаратная ошибка при записи данных, после чего логическая прослойка драйвера пыталась повторить неудавшуюся операцию несколько раз, но это не помогало и запись не отрабатывала. В особо неудачных случаях это совпадало с моментом записи snapshot, что и приводило к переходу файловой системы в режим только чтения. После подобных ошибок и перехода файловой системы в read-only потребуется отмонтировать ф/с, выполнить её проверку с восстановлением новой версией chkqnx6fs и заново подмонтировать. Либо выполнить перезагрузку, добавив проверку перед монтированием диска.

[GrayCat]

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

А того варианта chkqnx6fs, который входит в QNX6.5.1 (SP1) -- недостаточно в таких случаях?

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

Хорошо. А можем мы как-то из своих программ хотя бы обнаружить момент возникновения такой каки? Выдать оператору окно "Перезагрузись!" или что-то в этом роде...

Записи write() кода ошибки не возвращают, с их точки зрения всё ОК.

После подобных ошибок и перехода файловой системы в read-only потребуется отмонтировать ф/с, выполнить её проверку с восстановлением новой версией chkqnx6fs и заново подмонтировать. Либо выполнить перезагрузку, добавив проверку перед монтированием диска.

Ещё вопрос: а откат к QNX4fs -- поможет? На старых QNX бывали проблемы с ФС, но их хоть видно было...

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

А того варианта chkqnx6fs, который входит в QNX6.5.1 (SP1) -- недостаточно в таких случаях?

В некоторых случаях, например, если фс соскочила в read-only после неудачной попытки записать snapshot, достаточно даже простого перемонтирования файловой системы и она сама восстановит работу.
У новой версии chkqnx6fs в дополнение к исправлениям bitmap добавлена возможность починки одного из суперблоков.

Хорошо. А можем мы как-то из своих программ хотя бы обнаружить момент возникновения такой каки? Выдать оператору окно "Перезагрузись!" или что-то в этом роде...

В системном журнале фиксируются сообщения о ошибках работы с диском/контроллером, но они не обязательно должны приводить к поломке файловой системы и переходу её в R/O.

Ещё вопрос: а откат к QNX4fs -- поможет? На старых QNX бывали проблемы с ФС, но их хоть видно было...

Предположение справедливое и думаю стоит протестировать поведение ошибок с другими фс.