пятница, 21 января 2011 г.

Отключение сбойного жесткого диска без остановки сервера

Придя сегодня на работу, обнаружил, что девелоперский сервер в глубокой "задумчивости". При попытке пинговать его выявилась значительная потеря пакетов. Через минуту смог залогиниться через SSH - сказывались потери пакетов. Первый делом на проблемной машинке глянул
# dmesg | tail
SCSI device sdb: 490350672 512-byte hdwr sectors (251060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00 tag 0
         res 40/00:00:5f:00:00/00:00:00:00:00/e0 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: configured for UDMA/33
ata3: EH complete
SCSI device sdb: 490350672 512-byte hdwr sectors (251060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00 tag 0
         res 40/00:00:5f:00:00/00:00:00:00:00/e0 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: configured for UDMA/33
ata3: EH complete
Видимо один из 4-х дисков приказал долго жить и его срочно нужно отключить от RAID. Самое интересное, что за полтора часа, пока сервер загибался, сбойный винт не пометило как сбойный.
Чтобы извлечь нужный диск и потом отключить его физически нужно знать его S/N (у нас стоят 4 одинаковых WDC WD2502ABYS - поэтому просто по производителю глянуть не получится).
Пробую найти сбойный диск перебирая все винты на сервере
for hdd in sda sdb sdc sdd; do smartctl -d ata -a /dev/$hdd | grep ^194; done
Скрипт залипает на /dev/sdb, исключаю его из перебора и пробую вновь. На этот раз отрабатывает без ошибок.
Теперь остается выяснить его серийный номер (S/N):
# ls -l /dev/disk/by-id/scsi-SATA_WDC_WD2502ABYS-_WD-WCAT1E8* |grep sdb$
lrwxrwxrwx 1 root root  9 Окт 25 10:39 /dev/disk/by-id/scsi-SATA_WDC_WD2502ABYS-_WD-WCAT1E882772 -> ../../sdb
Получается что его S/N WCAT1E882772. Теперь извлекаем его из raid:
mdadm --manage /dev/md0 --fail /dev/sdb1 --remove /dev/sdb1
mdadm --manage /dev/md1 --fail /dev/sdb2 --remove /dev/sdb2
Остается остановить диск, чтобы система не пыталась его переинициализировать:
# ls -ld /sys/class/scsi_device/*/device/block:sdb
lrwxrwxrwx 1 root root 0 Янв 21 10:03 /sys/class/scsi_device/2:0:0:0/device/block:sdb -> ../../../../../../block/sdb

# echo 1 > /sys/class/scsi_device/2:0:0:0/device/delete
Проверяем, остановлен ли диск
# dmesg |tail

SCSI device sdb: 490350672 512-byte hdwr sectors (251060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata3.00: disabled
Осталось вытащить его из сервера и сдать по гарантии =)








среда, 19 января 2011 г.

Синхронизация времени в Windows

Сетаплю винду на компе для нового сотрудника, решил разобраться в синхронизации времени в винде. Раньше обходился NetTime и отключал встроенную службу "Windows Time".
Поискал в инете - получилось что-то вроде:
\> net time /setsntp:172.16.0.1
\> net time /querysntp
The current SNTP value is: 172.16.0.1

\> net stop w32time
\> net start w32time
Теперь время синхронизируется через службу "Windows Time"

Сломался hibernate на моей eeepc'шке

Началось все со странной перезагрузки при попытке разбудить ноутбук из hibernation. Вроде процесс восстановления прошел, но вместо скринсейвера я увидел логотип асуса и последующую загрузку и проверку разделов на винте. Время было позднее и я не придал этому никакого значения - рещил, что был аппаратный сбой.
На следующий день история повторилась на работе. Времени разбираться не было и оставил как есть. Ближе к вечеру появилось свободное время - решил разобраться, что сломалось. Прикинул что дня три назад все еще работало, а значит нужно искать проблему в изменениях за последние двое суток. Вспомнилось, что делал обновления до текущего Debian Squeeze и обновилось что-то в районе ядра и прошивки для беспроводной карточки. Дома, где впервые заметил проблему, ноут засыпает с включенным wi-fi - и сразу напрашивалось, что сбоит включенная карточка в момент выхода ноута из спячки.
Попробовал сделать hibernate и снова включить ноут, но уже с отключенным wi-fi - результатом была та же перезагрузка. Начал искать причину среди недавних апдейтов ядра и системы засыпания. На тот момент стояло linux-image-2.6.32-5-686, uswsusp и pm-utils (работает поверх uswsusp). Поискал последние изменения в пакетной базе
$ grep 'status installed' /var/log/dpkg.log

2011-01-17 16:30:35 status installed linux-base 2.6.32-30
2011-01-17 16:31:09 status installed linux-image-2.6.32-5-686 2.6.32-30
2011-01-17 16:31:11 status installed firmware-linux-free 2.6.32-30
2011-01-17 16:31:11 status installed linux-libc-dev 2.6.32-30
Ядро обновилось с версии 2.6.32-29 на 2.6.32-30 - пошел читать changelog. Вроде ничего подозрительного не видно, решил глянуть upstream changelog, вот в нем и нашлось изменение в районе подсистемы PM / Hibernate
commit 012f9fdfd2965f573171f848d1aa46531cab7062
Author: Takashi Iwai 
Date:   Fri Dec 10 00:16:39 2010 +0100

    PM / Hibernate: Fix PM_POST_* notification with user-space suspend
    
    commit 1497dd1d29c6a53fcd3c80f7ac8d0e0239e7389e upstream.
    
    The user-space hibernation sends a wrong notification after the image
    restoration because of thinko for the file flag check.  RDONLY
    corresponds to hibernation and WRONLY to restoration, confusingly.
    
    Signed-off-by: Takashi Iwai 
    Signed-off-by: Rafael J. Wysocki 
    Signed-off-by: Greg Kroah-Hartman 

Полное описание комита
Решил откатиться на версию 2.6.32-29 и зафиксировать версию ядра, пока проблема не будет решена. Старую версию взял со snapshot.debian.org
Установка
$ wget http://snapshot.debian.org/archive/debian/20101211T031516Z/pool/main/l/linux-2.6/linux-image-2.6.32-5-686_2.6.32-29_i386.deb \
http://snapshot.debian.org/archive/debian/20101211T031516Z/pool/main/l/linux-2.6/linux-libc-dev_2.6.32-29_i386.deb \
http://snapshot.debian.org/archive/debian/20101210T205106Z/pool/main/l/linux-2.6/linux-base_2.6.32-29_all.deb \
http://snapshot.debian.org/archive/debian/20101210T205106Z/pool/main/l/linux-2.6/firmware-linux-free_2.6.32-29_all.deb
$ sudo dpkg -i *2.6.32*.deb
Фиксация версии в пакетной базе
$ sudo aptitude hold linux-image-2.6.32-5-686 firmware-linux-free linux-base linux-libc-dev
Перезагрузка и пробую засыпать на диск:
pm-hibernate
- все в порядке, включение прошло без проблем, осталось отписаться о проблеме разработчикам.