среда, 13 октября 2010 г.

О необходимости тестирования памяти

До недавнего времени верил, что для проверки планки памяти на живучесть достаточно один раз прогнать memtest86+ и можно ставить. Вот только после установки двух планок памяти (по гигу каждая) в комп, он начал спонтанно перезагружаться с завидной частотой.
Вернул старые планки (по 512MB) и все заработало как раньше. Две новые поставил на стенд и запустил memtest на бесконечное тестирование. После одного прогона нашло одну ошибку при битовых операциях. Решил поменять планки местами. До ухода домой успело проверить два раза и не нашло ни одной ошибки - оставил на ночь. Утром из девяти повторений теста нашло две ошибки в процессе выполнения третьего.
Вот сейчас сижу и думаю, что может быть причиной "плавающей" ошибки при работе с памятью. На перегрев не похоже - стенд стоит без корпуса и прекрасно охлаждается. Возможно память глючит на максимальной частоте, но в компе, где она приводила к ребутам, планки работали на пониженной частоте (планки A-Data DDR400, работали как DDR333).

понедельник, 11 октября 2010 г.

Восстановление битого раздела

Начало истории тут
В субботу вечером остановил все, что использует битый раздел. Потом создал образ с тома LVM и загрузил на отдельную машинку.
root@server # dd if=/dev/vg/badlv of=/mnt/tmp/badlv.bin bs=8M
root@server # smbclient -N //rescue/share
> lcd /mnt/tmp
> put badlv.bin
Там раздел монтировался через loop в read-only режиме.
root@rescue # mount -o ro,acl,loop /mnt/share/badlv.bin /mnt/tmp
На сервере создал раздел с XFS того же размера и запустил rsync с примонтированного образа на сервер.
root@server # lvcreate -n newlv -L50G vg
root@server # mkfs.xfs /dev/vg/newlv
root@server # mount /dev/vg/newlv /mnt/repaired
root@rescue # rsync -aAz /mnt/tmp/ server:/mnt/repaired
Утром в воскресенье меня ждала пачка сообщений о том, что на новом разделе XFS закончилось место и копирование накрылось медным тазом. Перед повторным запуском добавил 20GB к емкости раздела и расширил том и снова запустил rsync.
root@server # lvresize -L+20G /dev/vg/newlv
root@server # xfs_growfs /mnt/repaired
На этот раз копирование заняло все воскресенье и часть ночи понедельника, но данные успешно перенеслись, за исключением пары битых атрибутов ACL (скорее всего попытка их чтения на сервере и приводила к kernel panic)



понедельник, 4 октября 2010 г.

Kernel panic debug

На днях отлаженный скрипт бэкапа начал рапортовать об обрыве связи в процессе создания бэкапа. Происходило это в произвольный момент времени ночью.
Очевидно, что сбой вызывал процесс бэкапа, ведь нагрузка на дисковую подсистему создается много большая, чем при штатной работе сервера днём. В пользу сбоев дисковой системы говорил и тот факт, что не было сообщения об ошибке в системных журналах. Т.е. вероятнее всего имею дело с kernel panic. На сервере стоит опция panic=30 - при панике ядра через 30 секунд произойдет автоматическая перезагрузка сервера.
После некоторых раздумий выработал несколько решений:

  • Отключить опцию panic=30 и утром посмотреть что за сообщение будет на экране. У этого подхода есть минус, если сообщение окажется больше одного экрана, то не получится его посмотреть целиком.
  • Собрать null-модемный кабель и загрузить систему с перенаправлением системной консоли в последовательный порт, а для отлова сообщения об ошибке использовать отдельную машину, подключенную к null-модемному кабелю.
  • Случайно нагуглил еще один подход. Он состоит в загрузке дополнительного модуля netconsole, который выполняет роль null-модемного кабеля через IP сеть. Сообщение передается в UDP пакетах и чтобы его смотреть достаточно использовать netcat.

Выбрал последний подход. Загрузил модуль с параметрами:
modprobe netconsole netconsole="src-port@src-ip/src-iface,dst-port@dst-ip/dst-mac"

У себя на компьютере запустил netcat nc -l -u -p dst-port, где заменил src-/dst- константы на соответствующие параметры. Утром меня ждало сообщение о сбое в модуле reiserfs. Проверка радздела на 70GB заняла более полутора часов, причем мое терпение лопнуло, после начала проверки семантики FS, после проверки BTREE структуры. Впереди еще предстоит починка FS и спасение данных, но мое отношение к reiserfs здорово переменилось, теперь подумываю о миграции на XFS/JFS.
Для себя сделал вывод, что иметь нуль-модемный кабель + свободный COM-порт на соседней машинке - это must-have для любого сисадмина.