Как я могу диагностировать "замороженные" программные устройства Linux?

У меня есть сервер под управлением Linux 3.2.12 32-битный i686 с 13 дисками: 1 загрузочный диск и 3 устройства raid5 по 4 диска в каждом.

/ proc / mdstat показывает

Personalities : [raid1] [raid10] [raid6] [raid5] [raid4] 
md2 : active raid5 sdd1[3] sdc1[2] sdb1[1] sda1[0]
    5860535808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md1 : active raid5 sdk1[3] sdj1[2] sdi1[1] sdh1[0]
    4395407808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md3 : active raid5 sdl1[0] sdm1[1] sdf1[3] sde1[2]
    5860535808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

unused devices: <none>

Моя проблема заключается в том, что второй раз за три дня один из дисков raid вызывает блокировку любого процесса, который пытается прочитать с него. Никакой сигнал не может завершить этот процесс, и мне нужно перезагрузить компьютер, чтобы он снова заработал. Тем не менее, диски выглядят нормально после перезагрузки, и статус рейда выглядит нормально, и в журнале ядра нет никаких полезных сообщений об ошибках, кроме зависания процессов.

Я запустил smartctl на всех дисках, о которых идет речь, и они кажутся нормальными.

Что еще я могу проверить, чтобы попытаться диагностировать это?

Вот исключения из журнала ядра, которые выглядят полуинтересными. Но обратите внимание, что "не удается отправить ioctl в раздел" существует всегда, и поиски показали, что это было безобидное предупреждение.

Каждые 900 секунд:

...
Aug 20 18:34:01 [kernel] [  931.249505] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:01 [kernel] [ 1831.302297] scsi_verify_blk_ioctl: 2 callbacks suppressed
Aug 20 18:49:01 [kernel] [ 1831.302300] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:01 [kernel] [ 1831.302302] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:01 [kernel] [ 1831.302774] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:01 [kernel] [ 1831.302776] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.333538] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.333540] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.358068] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.358071] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.414331] mdadm: sending ioctl 1261 to a partition!
Aug 20 18:49:02 [kernel] [ 1831.414334] mdadm: sending ioctl 1261 to a partition!
Aug 20 19:04:01 [kernel] [ 2731.070794] scsi_verify_blk_ioctl: 2 callbacks suppressed
...

О времени, когда проблема обнаруживается:

Aug 21 13:38:32 [kernel] [69601.312055] INFO: task kjournald:26008 blocked for more than 600 seconds.
Aug 21 13:38:32 [kernel] [69601.312057] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 21 13:38:32 [kernel] [69601.312059] kjournald       D 00000000     0 26008      2 0x00000000
Aug 21 13:38:32 [kernel] [69601.312063]  eb5ccc80 00000046 00000000 00000000 00000000 e81e0070 e81e020c f6205900
Aug 21 13:38:32 [kernel] [69601.312068]  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug 21 13:38:32 [kernel] [69601.312072]  00000000 00000000 00000000 00000000 00000000 00000001 c0b66230 e81e0280
Aug 21 13:38:32 [kernel] [69601.312077] Call Trace:
Aug 21 13:38:32 [kernel] [69601.312083]  [<c013cbe5>] ? prepare_to_wait+0x15/0x55
Aug 21 13:38:32 [kernel] [69601.312088]  [<c0217df5>] ? journal_commit_transaction+0xdb/0xca6
Aug 21 13:38:32 [kernel] [69601.312090]  [<c013ca68>] ? wake_up_bit+0x16/0x16
Aug 21 13:38:32 [kernel] [69601.312093]  [<c0132c3d>] ? lock_timer_base+0x19/0x35
Aug 21 13:38:32 [kernel] [69601.312095]  [<c0132cb8>] ? try_to_del_timer_sync+0x5f/0x65
Aug 21 13:38:32 [kernel] [69601.312098]  [<c021ade6>] ? kjournald+0xa6/0x1a2
Aug 21 13:38:32 [kernel] [69601.312101]  [<c013ca68>] ? wake_up_bit+0x16/0x16
Aug 21 13:38:32 [kernel] [69601.312103]  [<c021ad40>] ? journal_grab_journal_head+0x31/0x31
Aug 21 13:38:32 [kernel] [69601.312106]  [<c013c778>] ? kthread+0x65/0x6a
Aug 21 13:38:32 [kernel] [69601.312108]  [<c013c713>] ? kthread_stop+0x47/0x47
Aug 21 13:38:32 [kernel] [69601.312111]  [<c0830b36>] ? kernel_thread_helper+0x6/0xd
Источник

1 ответ

Решение

Сначала обновите ваше ядро. Это конкретное ядро ​​содержало ошибку, из-за которой различные ioctl выводили эти предупреждения (и, возможно, не выполнялись) в определенных конфигурациях mdraid и LVM.

Если исправленное ядро ​​не решает проблему, запустите расширенную самопроверку на всех ваших дисках. Обратите внимание, что самотестирование может занять несколько часов для каждого диска и слегка ухудшит производительность во время работы, поэтому его следует запускать во время низкой активности системы. Например, чтобы запланировать самотестирование на 11 часов вечера:

at 11 pm <<JOB
for drive in /dev/sd?
do
    smartctl -t long $drive || :
done
JOB

Позже на следующий день проверьте результаты теста:

for drive in /dev/sd?
do
    echo Test results for drive $drive
    smartctl -l selftest $drive || :
done

Если обновление ядра не устранило проблему, то вы можете найти диск, который не прошел самопроверку.

Если вы не нашли диск, который не прошел самопроверку, все равно проверьте атрибуты диска.

for drive in /dev/sd?
do
    echo Attributes for drive $drive
    smartctl -A $drive || :
done

Обратите внимание, что некоторые из этих атрибутов могут указывать на проблемы, даже если они не помечены как сбойные; поэтому найдите эксперта, чтобы изучить их, или приложите их к своему вопросу.

Источник
Другие вопросы по тегам