Проблемы с ext4 после отключения питания.
Привет.
Недавно случайно задел сетевой фильтр и комп выключился. До выключения система активно использовалась(шла компиляция в три потока, работали торренты, играла музыка, был запущен браузер и т.д. - в общем, работа шла полным ходом). После перезагрузки на на ФС были обнаружены многочисленные ошибки. Вплоть до того, что не помогала автоматическая чистка fsck. Запустить всё удалось только после перехода в single mode и ручного прогона fsck.
Сейчас система загружается, работает, но иногда бесповоротно виснет(почти мгновенно - замирает музыка, не отвечают иксы, чуть позже перестаёт двигаться мышь, а ещё чуть позже компьютер перестаёт отвечать на пинги). Зависает при активном обращении к разделам /usr и /var(ну, к примеру, я специально несколько раз пробовал запустить emerge -ueNDv system: стабильно на сборке примерно 100-го пакета из 300 зависает - не одного и того же пакета, каждый раз на разном, так что проблема точно не в каком-то одном ebuild'е). Т.е. повторить ошибку я могу без проблем, но вот локализовать проблему точно пока не могу. Такое впечатление, что система виснет из-за долгого и частого обращения к винту. Например, пересборка ядра(на моём железе примерно 15-20 минут) проходит отлично. А вот сборка чего-нибудь побольше зависает.
Последние, перед зависанием сообщения в /var/log/messages:
Jan 18 17:47:37 damned kernel: EXT4-fs (sda6): Jan 18 17:47:37 damned kernel: EXT4-fs (sda5): error count: 73 Jan 18 17:47:37 damned kernel: EXT4-fs (sda5): initial error at 1293337608: __ext4_get_inode_loc:4950error count: 1 Jan 18 17:47:37 damned kernel: EXT4-fs (sda6): initial error at 1293328331: ext4_mb_generate_buddy:718 Jan 18 17:47:37 damned kernel: EXT4-fs (sda6): last error at 1293328331: ext4_mb_generate_buddy:718 Jan 18 17:47:37 damned kernel: : inode 257188: block 532218 Jan 18 17:47:37 damned kernel: EXT4-fs (sda5): last error at 1293340291: __ext4_get_inode_loc:4950: inode 257196: block 532218
Но, после того, как провёл дополнительные тесты(открываю два терминала одновременно - в одном tailf /var/log/messages, в другом emerge -ueNDv system), оказалось, что зависает не непосредственно на этом сообщении, а через некоторое время - от пяти минут до часа, так что не уверен, что именно эта ошибка виновата в зависании.
К сожалению, мне пока не удалось нагуглить что-нибудь внятно(по ошибке выдаётся слишком много информации не по теме, а как составить внятный запрос я пока не придумал, буду признателен, если кто подскажет).
Файловая система - ext4 на всех разделах, кроме /boot(здесь ext2, но с ним и проблем нет). Разделы, на которых выскакивает ошибка в логах(sda5 и sda6) - это /usr и /var.
Винчестер новый, ещё на гарантии(куплен незадолго до нового года, до сбоя питания работал отлично, без нареканий). С LiveCD прогонял неоднократно fsck с разными опциями(fsck -f, -c, -a) - всё нормально(ну, непосредственно после сбоя, разумеется находит ошибки и исправляет, но тот же ключ -c никаких бедов не показывает).
Куда ещё можно посмотреть?
Незадолго до сбоя пересобирал ядро(включал v4l) - если мне не изменяет память, больше ничего не трогал(сейчас отключил назад). Но, мало ли, поэтому вопрос, мог ли я что-нибудь "не то" в ядре включить? Какие опции показать(или весь конфиг выложить)?
uname -a Linux damned 2.6.36-zen1-cppmm-v12 #6 ZEN SMP Tue Jan 18 17:29:27 NOVT 2011 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ AuthenticAMD GNU/Linux
- Для комментирования войдите или зарегистрируйтесь
скорее всего основной
скорее всего основной проблемы не решит, но при сбоях стоит проверить систему на наличие битых библиотек, исполняемых файлов и т.д.
примерно так ))
еще бы хорошо посмотреть вывод
smartctl --all /dev/sda
Цитата: скорее всего основной
Спасибо, попробую. А разве revdep-rebuild этого не делает?
Вот вывод smartctl:
Интересно, что это оно там за ошибки нашло.
возможно более опытные
возможно более опытные коллеги меня опровергнут, но по-моему винчестеру хана :( прошивки на твой винт нету, т.ч. я бы уже стоял в очереди в гарантийку, чтобы обменять ;)
Блин. Я старые винты(до этого
Блин.
Я старые винты(до этого три 80-ки стояли) уже поснимал и всю инфу перекинул(ну и собственно систему с них перенёс сюда). Бекапы-то есть, но очень лениво опять назад перекидывать, нести в сервис и т.д. А как-то ещё проверить можно? Просто тот же smartctl -H говорит, что всё нормально. Ну или может, где почитать подробнее о этих ошибках?
Поддерживаю - хана! :) Вот
Поддерживаю - хана! :)
Вот здесь
говорит о том, у тебя кусок данных не записался (т.е. ко всему у тебя нарушена целостность данных и большой вопрос: куда это попало - зависит от твоей удачи :) ). Обычно это бывает, когда relocation table переполнена.
Странно, что у тебя при этом
Т.е. сбой произошел в самом диске. Возможно, что low-level формат решит проблему (бывали такие случаи).
Кстати, сервис, скорее всего, претензию не примет (и будет прав! :) ), поскольку smart-event'а еще нет!
И еще: почему у вас диск ни разу не тестирован?! Срочно прогнать короткие и длинные тесты. Возможно smart-event'ы появятся, тогда и с сервисом сможете по-другому говорить.
Тесты гоняю. short и
Тесты гоняю. short и conveyance прошли без ошибок. Long ещё идёт.
Попробовал ещё загрузиться с System Rescue CD, примонтировать разделы, войти туда в chroot и запустить всё тот же emerge -ueNDv system. Прошло без ошибок. Все 300 пакетов. Так же натравил ещё несколько раз badblocks на все разделы по очереди - ничего. Всё отлично работает.
А можно по подробнее про smart-event'ы и low-level форматирование? Никогда таким заниматься не приходилось.
Стоит ли это воспринимать, как надежду на то, что диск таки жив и у меня получится без походов в сервис его вылечить? :)
cppmm
- доки по sys-apps/smartmontools
и слава богу... :) это перезапись служебной дорожки, давно сам этим уже не занимался, даже не знаю, как там ситуация с новыми терабайтными дисками - ищите в Гугле, но имейте ввиду, что гарантию вы, скорее всего, после него потеряете.
Нет. Это означает, что у вас негарантийный случай и вам его не заменят.
В принципе вы им пользоваться можете, только включите постоянный смарт-мониторинг и тестирование (на десктопе/ноуте я делаю короткое тестирование при каждом старте, на серверах: короткое - еженочно, а длинное - еженедельно) с выдачей сообщений об ошбках.
Все-таки попробуйте поменять по гарантии (покажите ошибки СМАРТ-диагностики, - если персонал не очень грамотный или очень знакомый, может и прокатит :) ).
В конце концов можете окончательно убить диск старым хакерским способом... :D и тогда уж точно поменяют.
SysA написал(а): В конце
Как? жутко интересно :))
Скажи мне - и я забуду, покажи мне - и я не смогу запомнить, привлеки меня к участию - и я пойму...
Поищите... в Рунете было
Поищите... в Рунете было много инфы.
А мы сами не местные, такими делами не занимаемся... :)
Цитата: - доки по
Спасибо, почитаю.
Длинный тест, всё-таки нашёл ошибку:
Похоже, где-то там всё-таки что-то побилось.
Попробую всё-таки отнести по гарантии.
Спасибо за помощь.
cppmm написал(а): А разве
Он проверяет библиотеки на совместимость версий и т.п., а не на изменения в файлах
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.