mptscsih: ioc0: задача прерывается: SUCCESS (rv = 2002) вызывает 30-секундное зависание

Ввод / вывод в моем программном обеспечении RAID6 часто останавливается примерно на 30 секунд, после чего все возвращается в нормальное состояние.

После завершения замораживания это помещается в системный журнал:

Mar 14 18:43:57 server kernel: [35649.816060] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 68 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.149020] mptbase: ioc0: LogInfo(0x31140000): Originator={PL}, Code={IO Executed}, SubCode(0x0000) cb_idx mptscsih_io_done
Mar 14 18:43:58 server kernel: [35651.151962] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff8807b02dfe80)
Mar 14 18:43:58 server kernel: [35651.151967] mptscsih: ioc0: attempting task abort! (sc=ffff88002a7f30c0)
Mar 14 18:43:58 server kernel: [35651.151972] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 6c 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.151981] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff88002a7f30c0)
Mar 14 18:43:58 server kernel: [35651.151984] mptscsih: ioc0: attempting task abort! (sc=ffff8804120e5ec0)
Mar 14 18:43:58 server kernel: [35651.151988] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 70 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.151996] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff8804120e5ec0)
Mar 14 18:43:58 server kernel: [35651.151999] mptscsih: ioc0: attempting task abort! (sc=ffff880154afb280)
Mar 14 18:43:58 server kernel: [35651.152020] sd 5:0:23:0: [sdy] CDB: Read(10): 28 00 6c 52 74 58 00 04 00 00
Mar 14 18:43:58 server kernel: [35651.152029] mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff880154afb280)

Я погуглил ошибку, и кто-то предложил попробовать использовать 1,5 Гбит / с вместо 3,0 Гбит / с. Используя lsiutilя изменил скорость ссылки:

# lsiutil -p 1 -i 

Firmware Settings
-----------------
SAS WWID:                       500605b002c0f680
Multi-pathing:                  Disabled
SATA Native Command Queuing:    Enabled
SATA Write Caching:             Enabled
SATA Maximum Queue Depth:       32
Device Missing Report Delay:    0 seconds
Device Missing I/O Delay:       0 seconds
Phy Parameters for Phynum:      0    1    2    3    4    5    6    7
  Link Enabled:                 Yes  Yes  Yes  Yes  Yes  Yes  Yes  Yes
  Link Min Rate:                1.5  1.5  1.5  1.5  1.5  1.5  1.5  1.5
  Link Max Rate:                1.5  1.5  1.5  1.5  1.5  1.5  1.5  1.5
  SSP Initiator Enabled:        Yes  Yes  Yes  Yes  Yes  Yes  Yes  Yes
  SSP Target Enabled:           No   No   No   No   No   No   No   No
  Port Configuration:           Auto Auto Auto Auto Auto Auto Auto Auto
Target IDs per enclosure:       1
Persistent mapping:             Enabled
Physical mapping type:          None
Target ID 0 reserved for boot:  No
Starting slot (direct attach):  0
Target IDs (physical mapping):  8
Interrupt Coalescing:           Enabled, timeout is 16 us, depth is 4

Это не помогло.

Я попытался изменить «Device Missing I / O Delay» на 32. Это тоже не помогло.

Я попытался изменить / sys / class / scsi_device / * / device / timeout с 30 на 100, а затем на 3. Все не удалось.

$ uname -a
Linux server 3.2.0-0.bpo.1-amd64 #1 SMP Sat Feb 11 08:41:32 UTC 2012 x86_64 GNU/Linux
$ grep LSISAS1068E /var/log/messages
Mar 13 15:47:44 server kernel: [   21.082363] scsi5 : ioc0: LSISAS1068E B3, FwRev=01210000h, Ports=1, MaxQ=483, IRQ=45
$ modinfo mptscsih
filename:       /lib/modules/3.2.0-0.bpo.1-amd64/kernel/drivers/message/fusion/mptscsih.ko
version:        3.04.20
license:        GPL
description:    Fusion MPT SCSI Host driver
author:         LSI Corporation
srcversion:     85D42A00FEBA3C95555E3AF
depends:        scsi_mod,mptbase
intree:         Y
vermagic:       3.2.0-0.bpo.1-amd64 SMP mod_unload modversions 
$ cat /sys/block/sdae/device/model
ST3000DM001-9YN1
$ cat /sys/block/sdae/device/rev
CC4C

Проблема возникает крайне редко, если есть только операции чтения или записи: я могу читать или записывать 1 ТБ без проблем. Проблема , кажется, возникает , когда есть оба операций чтения и записи. На raid6 это происходит, если вы пишете файл, размер которого меньше размера полосы, и у вас уже нет кэша полосы (в этом случае полоса должна быть прочитана для вычисления новой контрольной суммы).

Система не является виртуальной машиной.

В чем причина проблемы? Как избавиться от 30 секунд замораживания?

Редактировать: дополнительное тестирование

Я нашел хороший тестовый набор, который, кажется, провоцирует проблему. Он содержит файлы, размер которых меньше размера полосы, что приводит к повторному вычислению четности, что приводит к большому количеству операций чтения в сочетании с операциями записи.

Я должен признать, что я не думал, что планировщик очереди будет иметь какое-либо влияние на эту проблему. Я был неправ. Понятно, что deadlineнамного хуже остальных. Никто из них не решает проблему.

# cat /sys/block/sdaa/queue/scheduler
noop deadline [cfq]

Изменение планировщика noopприводит к возникновению проблемы через 100-120 секунд.

parallel echo noop \> {} ::: /sys/block/sd*/queue/scheduler

Изменение планировщика deadlineприводит к возникновению проблемы через 20-30 секунд.

parallel echo deadline \> {} ::: /sys/block/sd*/queue/scheduler

Изменение планировщика cfqприводит к возникновению проблемы через 120-300 секунд.

parallel echo cfq \> {} ::: /sys/block/sd*/queue/scheduler

Edit2

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

MPTSCSIH-Driver Release Notes от LSI смотреть интересно.

Major Changes For Version 2.06.75.00-1
Release Date:  12/10/2007

General Changes
Functionality
•   Task Aborts for commands to a Volume are returned as FAILED and not sent to FW.

Какая версия вашего драйвера? ( modinfo mptscsih)

Используйте эту ссылку для получения информации о прошивке Seagate о вашем жестком диске Barracuda 3 ТБ. Вы должны ввести серийный номер, чтобы получить подробную информацию.

Обновление: примерьте. smartctl -i /dev/sdaaЯ только что проверил его на SCSI и SATA и получил серийный номер.

Вы пытались изменить свои планировщики ввода / вывода?

   mccoy:/sys/block/sdb/queue # cat scheduler 
   noop anticipatory deadline [cfq] 
   mccoy:/sys/block/sdb/queue # echo noop > scheduler 
   mccoy:/sys/block/sdb/queue # cat scheduler 
   [noop] anticipatory deadline cfq 

По умолчанию используется CFQ, как правило, для большинства систем «в настоящее время».

Для сравнения планировщиков ввода / вывода сделайте следующее:

Читать тестирование:

# echo 3 > /proc/sys/vm/drop_caches

Это позволит вам проверить диск, а не кэшированные страницы оперативной памяти, это очистит кэш.

Написать тестирование:

Скопируйте ваши файлы несколько раз одновременно. Как только записи завершены, выдайтеsync

Если вы тестируете оба, вы можете захотеть drop_cachesи позвонить, syncкогда копия будет готова. В дополнение к планировщику есть настраиваемые для каждого планировщика. Но быстрая проверка состояла бы в том, чтобы изменить планировщик и повторить попытку. Если у вас есть хороший контроллер noop, выгрузите «Планирование ввода / вывода» на него и не будете выполнять планирование данных на уровне ОС.

Во всяком случае, стоит попробовать, и нужно только echoвернуть его обратно.

Я решил проблему, купив карту SAS2008. Он все еще немного жалуется в журнале, но никогда не блокирует дисковый ввод-вывод. Также я проверил, что он поддерживает диски SATA 4 ТБ, тогда как LSI-SAS1068E поддерживает только 2 ТБ.

Поскольку я буду возвращать LSI-SAS1068E продавцу, я не смогу опробовать другие предложения. Поэтому я закрываю вопрос здесь.