LH
Ветеран
Сообщений: 345
|
 |
« : 11 Сентябрь, 2010, 07:27:07 » |
|
В QNX4.25 при поиске файла с помощью find получил следующее сообщение:
$ find / -name file_name -print ... find: Cannot recurce into 'folder_name' - filesystem form an infinite loop ... где folder_name - полный путь к некоторой папке, в которой прикладные программы складывают данные.
При открытии этой папки (с помощью файлового менеджера ezfm ) или просмотре содержимого этой папки с помощью ls -l видно, что в ней имеется другая папка с пустым именем, или, другими словами, папка без имени.
Войти в эту "папку без имени" с помощью ezfm не удается, но после этой попытки происходит переход в корневую папку файловой системы. М.б. поэтому утилита find сообщает об infinite loop.
Удалить папку без имени так же не удается.
Пожалуйста объясните:
- в чем может быть причина образования такой папки?
- сможет ли chkfsys "вылечить" данную ошибку?
При загрузке ОС chkfsys запускается без ключа -u и, видимо, не находит причины для проверки файловой системы.
Спасибо.
|
|
|
Записан
|
|
|
|
Al
Пользователь
Сообщений: 89
|
 |
« Ответ #1 : 12 Сентябрь, 2010, 06:50:37 » |
|
Смотрю народ начал нарываться на этот весьма неприятный глюк в файловой системе QNX4. Меня такое поведение "как-бы отказоустойчивой" файловой системы уже порядком достало.  Решение: удалить вышестоящую папку с "битой" записью утилитой zap и далее уже пройтись chkfsys -u по диску. Другого решения я не нашел  Кстати, если с этим делом затянуть, файловая система может "посыпаться" дальше. Я в основном на VMWare работаю, так там весьма часто ФС сыпаться начинает, хоть и выключаюсь всегда по shutdown, один раз еле "откачал" 
|
|
« Последнее редактирование: 12 Сентябрь, 2010, 06:56:58 от Al »
|
Записан
|
|
|
|
LH
Ветеран
Сообщений: 345
|
 |
« Ответ #2 : 12 Сентябрь, 2010, 11:19:09 » |
|
На вс.сл. уточняю, что речь идет о файловой системе QNX4 в ОС QNX4. Судя по дате проблема случилась примерно год назад, на данный момент имеется 2 такие папки, данные пишутся довольно интенсивно.
Путь с удалением c помощью zap и дальнейшим chkfsys -u понятен, в папке довольно много данных спасать предварительно придется...
Хотелось бы понять: как возникает проблемная папка, это может быть ошибка моего приложения в момент создания папки или файла или что-то другое ( например - сбойный блок на жестком диске )?
ОС QNX4 работает самостоятельно, без VMWare.
P.S. я с такой ошибкой файловой системы встретился впервые ( за 17 лет работы в QNX4)
|
|
« Последнее редактирование: 12 Сентябрь, 2010, 14:21:55 от LH »
|
Записан
|
|
|
|
Al
Пользователь
Сообщений: 89
|
 |
« Ответ #3 : 13 Сентябрь, 2010, 11:07:44 » |
|
Кстати, а Вы случаем QCDR не пользуетесь?? А то есть у меня на неё подозрения, поскольку замечена в порче файловой системы... У меня проявляется еще в виде порчи содержимого исполняемого файла qcdr, видимо в кэше, поскольку после перезагрузки всё становится нормально.
|
|
« Последнее редактирование: 13 Сентябрь, 2010, 11:10:16 от Al »
|
Записан
|
|
|
|
LH
Ветеран
Сообщений: 345
|
 |
« Ответ #4 : 13 Сентябрь, 2010, 13:41:26 » |
|
Запись на CD с помощью qcdr используется регулярно.
Т.к. нас читают и разработчики qcdr - хотелось бы попросить Вас, Al, больше подробностей и обоснования Вашего предположения. Почему подрзрение именно на qcdr?
При выполнении записи ей на вход подается только уже созданный файл ISO-образа CD. Каким образом может произойти "порча"? Спасибо.
|
|
|
Записан
|
|
|
|
Олег Большаков
|
 |
« Ответ #5 : 13 Сентябрь, 2010, 14:40:29 » |
|
Каких-либо повреждений файловой системы при работе с QCDR я не замечал. В любом случае, если кто-то покажет нам, как повредить файловую систему QNX4 при помощи QCDR, то мы исправим эту ситуацию.
По поводу причины повреждения файловой системы QNX4 я также не могу сказать очень много. Вполне может быть, что работа системы была завершена некорректно, в момент записи на диск или появились бедблоки/ремапы. Всё это может зависеть от конкретной конфигурации системы в целом.
Al, уточните, пожалуйста, при работе с VMware вы тоже пользуетесь QCDR?
|
|
|
Записан
|
|
|
|
Al
Пользователь
Сообщений: 89
|
 |
« Ответ #6 : 13 Сентябрь, 2010, 14:46:41 » |
|
Al, уточните, пожалуйста, при работе с VMware вы тоже пользуетесь QCDR?
И в VMWare тоже, НО проблема точно не в VMWare, поскольку в целевой системе её нет, а данный глюк - присутствует. Я еще тему тут поднимал про неработоспособность qcdr с некоторыми приводами/чипсетами, так это только цветочки... Сейчас на своей системе (целевой) попробую воспроизвести ситуацию, когда "портится" содержимое исполняемого файла qcdr, там в начале несколько байт меняется и в итоге при попытке запуска она валится в SIGSEGV. А в целом могу сказать так, даже в конфигурации где чипсет/привод привод вроде как работают с qcdr - дальнейшее поведение системы непредсказуемо, "глюки" могут появлятся в самых разных местах, правда чаще всего заканчивается зависанием системы после нескольких операций с qcdr. ЗЫ у нас в инструкции к аппаратуре даже написано, что после записи на CD требуется перезагрузка системы 
|
|
« Последнее редактирование: 13 Сентябрь, 2010, 14:50:24 от Al »
|
Записан
|
|
|
|
LH
Ветеран
Сообщений: 345
|
 |
« Ответ #7 : 08 Октябрь, 2010, 05:53:59 » |
|
Прошло какое-то время и произошли странные события.
"Папка без имени" cама по себе исчезла, как будто ее и не было. Насколько я понимаю, проверка chkfsys с исправлением ошибок и записью нового .bitmap - файла не производилась.
Зато на другом контроллере обнаружилась подобная странность. Только образовалась не папка, а файл без имени. Т.е. есть размер, дата изменения файла, а имя пустое.
Есть ли какой-то способ удалить "файл без имени", кроме того, что сделать zap на папку, где он находится?
Спасибо.
|
|
|
Записан
|
|
|
|
|