Переключение ФС 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 бывали проблемы с ФС, но их хоть видно было...

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

[GrayCat]

Итак, версия о переходе в Read-Only из-за низкоуровневых ошибок диска (или интерфейса) находит всё больше подтверждений.
 
На одном из филиалов "испортился" винчестер. Сами QNX и Photon грузятся, но уже наш софт не поднимается. Поскольку приехали мы с уже подготовленным новым комплектом, то появилась возможность забрать диск к себе в лабу для подробных разборок.

Экспериментально пошагово установили, что файловая система почти сразу в R/O валится, при попытках запуска из Photon-а почти всего. Утилита "chkqnx6fs -f" выдаёт 7 мегабайт ругани про "File name too long" и "Cross-linked files", наталкивается на "Bad sector", и ничего не исправляет.
 
Хорошо. Дальше грузимся с нормального HDD, а больной подключаем вторым.
 
Натравили на диск Victoри-ю. В режиме "чтения", она действительно нашла две группы "плохих" секторов. Причём одна из групп в районе LBA № 620, т.е. в самом начале раздела -- видимо, пришлась куда-то на служебные области ФС. Но, проход Виктории в режиме "Remap Bad Sectors" показал, что это были "Софт-Бэды" -- они "исправились" без следа, т.е. без увеличения соответствующих счётчиков в SMART info ("Remaps" и "Pending Remaps" == 0 ), и без просадок скорости на графике чтения. Значит, это была просто неверная CRC в секторах, которая исправилась после перезаписи.
 
Теперь "chkqnx6fs -f" уже не находит "Bad sectors", но по-прежнему выдаёт несколько тысяч "File name too long" и "Cross-linked files", и всё так же не исправляет ничего.
 
Файлы на этом диске видятся. Читаются. Один раз даже удаётся открыть какой-нибудь файл на запись, но после этого всё -- отлуп. И не удаётся даже запустить на исполнение ни одну программу с него -- ругается "Read-only file system". Удалось ещё установить, что, например, функция pathfind() с запросом на поиск c атрибутами "rw", которая только что прекрасно всё находила, при переключении в R/O перестаёт находить даже саму себя ( argv[0], в смысле). Попробуем эту особенность применить для детектирования момента ахтунга.