Xen 4.1, падение fs с виртуалками вызывает падения при обращении к корню. как объяснить?
Ситуация следующая: Есть офисный сервер с xen (debian). Произошел троекратный сбой по питанию. После первого сбоя развалился raid5 (на котором виртуалки), но развалился не совсем — остался в режиме readwrite и начал медленно ресинхронизироватся. После второго сбоя побилась сама fs на этом рейде (ext3, data=ordered). После третьего сбоя по питанию (во время ресинхронизации рейда) fs перестала монтировался.
Вобщем стабилизировали питание, ресинхронизировали raid5, прогнали fsck по этой fs и по корню (на всякий случай). В корне ошибок не было, в этой fs все что были исправлены. Перезапустились.
После перезапуска начали происходить странные вещи: Если не запускать виртуалки — система работает как часы. А после запуска виртуалок система славливает ошибки по диску (в этой fs с виртуалками). Так вот после 3-4 ошибок в этой fs, ошибки начинают сыпатся при обращении и к корневой файловой системе.
Например, делаем:
# apt-cache search linux-image
— падает (внутри ядра) и обрывает выполнение apt-cache
И так почти с большинством бинариков: apt-*, xm, dd, aptitude…
Странно то что если перезагрузится и не запускать виртуалки — снова всё работает как часы.
В системе 2 raid5 (по разделам sda1+sdb1+sdc1 и sda2+sdb2+sdc2 на 3х дисках SATA)
Система: Linux lynx 3.2.0-4-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 GNU/Linux
В чем может быть подвох? Что может провацировать ошибки при работе с другой fs и как это можно поличить?
Нашел свой же старый вопрос и напишу ответ. Единственная причина такого поведения была в том что из за предшествующих перебоев в питании начались проблемы электрического кахарктера в одном из HDD. Это выносило мозг SATA контроллеру и он вел себя неадекватно. Заменили винт и теперь не используем те контроллеры, новые берем Adaptec у них таких проблем нет.
Правильно я понимаю, что вся система расположена на двух рейдах? Корень на одном, виртуалки на другом? Возможно перебои питания убили ту часть диска(ов), на которой расположены виртуалки так, что при попытке доступа туда, контроллер жесткого диска сходит с ума и начинает выдавать ошибки вообще, в т.ч. и на нормальной части диска(ов).
У Вас же уже есть запасной жесткий диск после такой аварии? Если нет, это очень опрометчиво. Срочно приобретайте и подменяйте по одному «боевые» диски и каждый из них сканируйте теми же badblocks.
Да, про рейды так и есть. Бекап есть — realtime реплика диска (drbd).
Вобщем как оказалось — оказался побит один файл — образ диска одной из виртуалок. При обращении к файлу — read/write/stat начинают отваливатся все fs.
Привести сервер в стабильность удалось загрузкой с более младшего ядра — 3.2.0-3-amd64. На этом ядре нормально отработала ситуация с ошибкой доступа inode и падение перестало быть массовым. При обращении к этой иноде (на ядре 3.2.0-3) raid пометил один диск как битый и его мы заменили. Проблема была исчерпана.
Судя по всему в ядре 3.2.0-4 (debian) скрыт какой то баг, от которого сносит крышу у рейдов при обращении к битой части рейда.
Средний
