Краткая версия: У меня есть отказавший массив RAID 5, на котором зависла куча процессов, ожидающих операций ввода-вывода; как я могу оправиться от этого?
Длинная версия: Вчера я заметил, что доступ к Samba был очень спорадическим; доступ к общим ресурсам сервера из Windows случайным образом полностью блокирует проводник после нажатия на один или два каталога. Я предположил, что это была проблема Windows, и оставил это. Сегодня проблема та же, поэтому я немного покопался; первое, что я заметил, это бег ps aux | grep smbd
дает много таких строк:
ben 969 0.0 0.2 96088 4128 ? D 18:21 0:00 smbd -F
root 1708 0.0 0.2 93468 4748 ? Ss 18:44 0:00 smbd -F
root 1711 0.0 0.0 93468 1364 ? S 18:44 0:00 smbd -F
ben 3148 0.0 0.2 96052 4160 ? D Mar07 0:00 smbd -F
...
Многие процессы застряли в состоянии "D". Бег ps aux | grep " D"
показывает некоторые другие процессы, включая мой сценарий ночного резервного копирования, каждый из которых в какой-то момент должен получить доступ к тому, установленному на моем RAID-массиве. После некоторого поиска в Google я обнаружил, что это могло быть связано с отказом массива RAID, поэтому я проверил /proc/mdstat
, который показывает это:
ben@jack:~$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdb1[3](F) sdc1[1] sdd1[2]
2930271872 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]
unused devices: <none>
И бег mdadm --detail /dev/md0
дает это:
ben@jack:~$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Sat Oct 31 20:53:10 2009
Raid Level : raid5
Array Size : 2930271872 (2794.53 GiB 3000.60 GB)
Used Dev Size : 1465135936 (1397.26 GiB 1500.30 GB)
Raid Devices : 3
Total Devices : 3
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Mon Mar 7 03:06:35 2011
State : active, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 1
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : f114711a:c770de54:c8276759:b34deaa0
Events : 0.208245
Number Major Minor RaidDevice State
3 8 17 0 faulty spare rebuilding /dev/sdb1
1 8 33 1 active sync /dev/sdc1
2 8 49 2 active sync /dev/sdd1
Я считаю, что это говорит о сбое sdb1, и поэтому массив работает с двумя дисками из трех «вверх». Некоторые советы, которые я нашел, говорят, что нужно проверять / var / log / messages на наличие уведомлений о сбоях, и, конечно же, их много:
ben@jack:~$ grep sdb /var/log/messages
...
Mar 7 03:06:35 jack kernel: [4525155.384937] md/raid:md0: read error NOT corrected!! (sector 400644912 on sdb1).
Mar 7 03:06:35 jack kernel: [4525155.389686] md/raid:md0: read error not correctable (sector 400644920 on sdb1).
Mar 7 03:06:35 jack kernel: [4525155.389686] md/raid:md0: read error not correctable (sector 400644928 on sdb1).
Mar 7 03:06:35 jack kernel: [4525155.389688] md/raid:md0: read error not correctable (sector 400644936 on sdb1).
Mar 7 03:06:56 jack kernel: [4525176.231603] sd 0:0:1:0: [sdb] Unhandled sense code
Mar 7 03:06:56 jack kernel: [4525176.231605] sd 0:0:1:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Mar 7 03:06:56 jack kernel: [4525176.231608] sd 0:0:1:0: [sdb] Sense Key : Medium Error [current] [descriptor]
Mar 7 03:06:56 jack kernel: [4525176.231623] sd 0:0:1:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
Mar 7 03:06:56 jack kernel: [4525176.231627] sd 0:0:1:0: [sdb] CDB: Read(10): 28 00 17 e1 5f bf 00 01 00 00
Для меня ясно, что устройство sdb не удалось, и мне нужно остановить массив, выключить, заменить его, перезагрузить, затем восстановить массив, вернуть его и смонтировать файловую систему. Я не могу заменить диск на замену в горячем режиме и не хочу оставлять массив работающим в ухудшенном состоянии. Я считаю, что я должен размонтировать файловую систему перед остановкой массива, но это не удается, и вот где я сейчас застрял:
ben@jack:~$ sudo umount /storage
umount: /storage: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
Он действительно занят; около 30-40 процессов ожидают ввода-вывода.
Что я должен делать? Должен ли я убить все эти процессы и попробовать еще раз? Разве это мудрый шаг, когда их нельзя остановить? Что будет, если я попытаюсь перезагрузиться?
Пожалуйста, дайте мне знать, что, по вашему мнению, мне следует делать. И, пожалуйста, спросите, нужна ли вам дополнительная информация для диагностики проблемы или помощи!
Я не думаю, что вам нужно останавливать массив. Просто выйдите из строя / dev / sdb, удалите его (я полагаю, это подключаемый жесткий диск) и подключите новый диск, который вы объявите как горячий резерв.
Вы не можете убить процесс, который пытается выполнить ввод-вывод. Что вам нужно сделать, так это использовать ленивый вариант размонтировать команда для удаления файловой системы из пространства имен файловой системы, даже если файлы в ней все еще открыты. Для получения дополнительной информации об этом (и других «причудах» этого аспекта дизайна Linux) см. Нил Браун.
umount -l /storage
Вы также можете остановить процесс samba, который остановит запись на диск и позволит завершить текущую запись, а не отключать файловую систему, в которую выполняется запись.