У меня есть сервер под управлением 32-разрядной версии Linux 3.2.12 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
Сначала обновите ядро. Это конкретное ядро содержало Жук из-за чего различные ioctl выводили эти предупреждения (и, возможно, завершали работу) в определенных конфигурациях mdraid и LVM.
Если исправленное ядро не решает проблему, запустите расширенную самопроверку на всех ваших дисках. Обратите внимание, что самопроверка может занять несколько часов для каждого диска и немного снизит производительность во время работы, поэтому ее следует запускать во время низкой активности системы. Например, чтобы запланировать начало самотестирования в 23:00:
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
Обратите внимание, что некоторые из этих атрибутов могут указывать на проблемы, даже если они не помечены как сбойные; так что найдите эксперта, который изучит их, или приложите их к своему вопросу.