mptscsih: ioc0: abortar tarefa: SUCESSO (rv = 2002) causa 30 segundos de congelamento

A E / S do meu software RAID6 geralmente congela por cerca de 30 segundos, após os quais tudo volta ao normal.

Após o congelamento, este é colocado no syslog:

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)

Eu pesquisei o erro no Google e alguém sugeriu tentar usar 1,5 Gbps em vez de 3,0 Gbps. Usando lsiutileu mudei a velocidade do link:

# 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

Isso não ajudou.

Tentei alterar 'Atraso de E / S ausente do dispositivo' para 32. Isso também não ajudou.

Tentei alterar / sys / class / scsi_device / * / device / timeout de 30 para 100 e depois para 3. Tudo falhou.

$ 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

O problema ocorre muito raramente se houver apenas operações de leitura ou gravação: Eu posso ler ou gravar 1 TB sem problemas. O problema parece surgir quando há operações de leitura e gravação. Em um raid6, isso acontece se você gravar um arquivo menor que o tamanho da faixa e ainda não tiver a faixa em cache (nesse caso, a faixa deve ser lida para calcular uma nova soma de verificação).

O sistema não é uma máquina virtual.

O que está causando o problema? Como faço para me livrar dos 30 segundos de congelamento?

Editar: testes adicionais

Encontrei um bom conjunto de testes que parece provocar o problema. Ele contém arquivos menores que o tamanho da faixa, forçando a recomputação da paridade, forçando muitas leituras combinadas com as gravações.

Devo admitir que não achei que o agendador de filas tivesse qualquer efeito sobre esse problema. Eu estava errado. É claro que deadlineé muito pior que os outros. Nenhum deles resolve o problema, no entanto.

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

Alterar o planejador para noopcausar o problema após 100-120 segundos.

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

Alterar o planejador para deadlinecausar o problema após 20 a 30 segundos.

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

Alterar o agendador para cfqcausar o problema após 120 a 300 segundos.

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

Edit2

Como o agendador tem efeito, estou pensando se o problema é causado por muitas solicitações em um período de tempo. Posso de alguma forma limitar o número de solicitações enviadas por segundo?

As notas de versão do driver MPTSCSIH da LSI parecem interessantes.

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.

Qual versão é o seu driver? ( modinfo mptscsih)

Use este link para obter informações do firmware da Seagate sobre sua unidade Barracuda de 3 TB. Você precisa inserir o número de série para obter detalhes.

Atualização: experimente smartctl -i /dev/sdaa. Acabei de testá-lo em SCSI e SATA e obtive o número de série dessa maneira.

Você já tentou alterar seus agendadores de E / S?

   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 

O padrão é CFQ normalmente para a maioria dos sistemas "atualmente".

Para comparar planejadores de E / S, faça o seguinte:

Leia o teste:

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

Isso garantirá que você esteja testando o disco e não as páginas em cache da RAM; isso limpará o cache.

Teste de gravação:

Copie seus arquivos várias vezes simultaneamente. Após a conclusão das gravações, umsync

Se estiver testando os dois, convém drop_cachesligar e ligar syncquando a cópia estiver concluída. Além do planejador, há ajustáveis ​​para cada planejador. Mas, um teste rápido seria alterar o agendador e tentar novamente. Se você tiver um bom controlador noop, transferirá o "I / O Scheduling 'para ele e não executará nenhum agendamento de dados no nível do SO.

De qualquer forma, vale a pena tentar e leva apenas um echopara configurá-lo de volta.

Resolvi o problema comprando uma placa SAS2008. Ele ainda reclama um pouco no log, mas nunca bloqueia a E / S do disco. Também testei que suporta unidades SATA de 4 TB, enquanto o LSI-SAS1068E suporta apenas 2 TB.

Como retornarei o LSI-SAS1068E ao vendedor, não poderei experimentar outras sugestões. Portanto, encerro a pergunta aqui.