mptscsih: ioc0: aborto de tarea: ÉXITO (rv = 2002) causa congelación de 30 segundos

La E / S en mi software RAID6 a menudo se congela durante unos 30 segundos, después de lo cual todo vuelve a la normalidad.

Una vez finalizado el congelamiento, esto se coloca en 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)

Busqué en Google el error y alguien sugirió intentar usar 1.5Gbps en lugar de 3.0Gbps. Usando lsiutilcambié la velocidad del enlace:

# 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

Eso no ayudó.

Intenté cambiar el 'Retraso de E / S de dispositivo perdido' a 32. Eso tampoco ayudó.

Intenté cambiar / sys / class / scsi_device / * / device / timeout de 30 a 100 y luego a 3. Todo falló.

$ 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

El problema ocurre extremadamente raramente si solo hay operaciones de lectura o escritura: puedo leer o escribir 1 TB sin ningún problema. El problema parece surgir cuando hay dos operaciones de lectura y escritura. En una incursión6 eso ocurre si escribe un archivo más pequeño que el tamaño de la franja y no tiene la franja en caché ya (en cuyo caso la franja debe leerse para calcular la nueva suma de verificación).

El sistema no es una máquina virtual.

¿Qué está causando el problema? ¿Cómo me deshago de los 30 segundos de congelación?

Editar: pruebas adicionales

He encontrado un buen conjunto de pruebas que parece provocar el problema. Contiene archivos que son más pequeños que el tamaño de la banda, lo que obliga a recalcular la paridad, lo que obliga a muchas lecturas combinadas con las escrituras.

Debo admitir que no pensé que el planificador de colas tendría ningún efecto sobre este problema. Estaba equivocado. Está claro que deadlinees mucho peor que los demás. Sin embargo, ninguno de ellos resuelve el problema.

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

Cambiar el programador a noophace que el problema surja después de 100-120 segundos.

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

Cambiar el programador a deadlinehace que el problema surja después de 20-30 segundos.

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

Cambiar el programador a cfqhace que el problema surja después de 120-300 segundos.

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

Edit2

Dado que el planificador tiene un efecto, estoy pensando si el problema es causado por demasiadas solicitudes en un período de tiempo. ¿Puedo de alguna manera limitar el número de solicitudes enviadas por segundo?

Las notas de la versión del controlador MPTSCSIH de LSI parecen interesantes.

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.

¿Qué versión es tu controlador? ( modinfo mptscsih)

Utilice este enlace para obtener información del firmware de Seagate sobre su unidad Barracuda de 3 TB. Debe ingresar el número de serie para obtener detalles.

Actualización: Pruébelo smartctl -i /dev/sdaa, acabo de probarlo en SCSI y SATA y obtuve el número de serie de esa manera.

¿Has intentado cambiar tus programadores 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 

El valor predeterminado es CFQ típicamente para la mayoría de los sistemas "actualmente".

Para comparar los planificadores de E / S, haga lo siguiente:

Leer pruebas:

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

Esto asegurará que esté probando el disco y no las páginas de RAM en caché, esto vaciará el caché.

Prueba de escritura:

Copie sus archivos varias veces simultáneamente. Una vez que las escrituras estén completas, emita unsync

Si está probando ambos, puede drop_cachesllamar y llamar synccuando la copia esté hecha. Además del planificador, hay sintonizables para cada planificador. Pero, una prueba rápida sería cambiar el programador y volver a intentarlo. Si tiene un buen controlador noop, descargará la "Programación de E / S" y no realizará ninguna programación de datos a nivel del sistema operativo.

De todos modos, vale la pena intentarlo y solo se necesita un echoretroceso.

He resuelto el problema comprando una tarjeta SAS2008. Todavía se queja un poco en el registro, pero nunca bloquea la E / S del disco. También he probado que admite unidades SATA de 4 TB, mientras que el LSI-SAS1068E solo admite 2 TB.

Como devolveré el LSI-SAS1068E al vendedor, no podré probar otras sugerencias. Por eso cierro la pregunta aquí.