mptscsih: ioc0: abandon de la tâche: SUCCESS (rv = 2002) provoque un gel de 30 secondes

Les E / S vers mon logiciel RAID6 se bloquent souvent pendant environ 30 secondes, après quoi tout revient à la normale.

Une fois le gel terminé, ceci est mis dans 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)

J'ai googlé l'erreur et quelqu'un a suggéré d'essayer d'utiliser 1,5 Gbps au lieu de 3,0 Gbps. En utilisant lsiutilj'ai changé la vitesse du lien:

# 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

Cela n'a pas aidé.

J'ai essayé de changer «Périphérique manquant I / O Delay» à 32. Cela n'a pas aidé non plus.

J'ai essayé de changer / sys / class / scsi_device / * / device / timeout de 30 à 100 puis à 3. Tout a échoué.

$ 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

Le problème se produit extrêmement rarement s'il n'y a que des opérations de lecture ou d'écriture: je peux lire ou écrire 1 To sans problème. Le problème semble se poser quand il y a deux opérations de lecture et d' écriture. Sur un raid6, cela se produit si vous écrivez un fichier plus petit que la taille de la bande et que la bande n'est pas déjà mise en cache (auquel cas la bande doit être lue pour calculer la nouvelle somme de contrôle).

Le système n'est pas une machine virtuelle.

Quelle est la cause du problème? Comment puis-je me débarrasser des 30 secondes de gel?

Edit: tests supplémentaires

J'ai trouvé un bel ensemble de tests qui semble provoquer le problème. Il contient des fichiers plus petits que la taille de bande, ce qui oblige à recalculer la parité, forçant ainsi un grand nombre de lectures combinées aux écritures.

Je dois admettre que je ne pensais pas que le planificateur de file d'attente aurait un effet sur ce problème. J'avais tort. Il est clair que deadlinec'est bien pire que les autres. Cependant, aucun d'entre eux ne résout le problème.

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

La modification de l'ordonnanceur noopentraîne l'apparition du problème après 100 à 120 secondes.

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

La modification de l'ordonnanceur deadlineentraîne l'apparition du problème après 20 à 30 secondes.

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

La modification de l'ordonnanceur cfqentraîne l'apparition du problème après 120 à 300 secondes.

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

Modifier2

Étant donné que le planificateur a un effet, je pense que si le problème est causé par trop de demandes dans un délai. Puis-je en quelque sorte limiter le nombre de demandes envoyées par seconde?

Les notes de version du pilote MPTSCSIH de LSI semblent intéressantes.

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.

Quelle version est votre pilote? ( modinfo mptscsih)

Utilisez ce lien pour obtenir des informations sur le micrologiciel Seagate concernant votre lecteur Barracuda 3 To. Vous devez entrer le numéro de série pour obtenir des détails.

Mise à jour: Essayez smartctl -i /dev/sdaa, je viens de le tester sur SCSI et SATA et j'ai obtenu le numéro de série de cette façon.

Avez-vous essayé de changer vos planificateurs d'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 

La valeur par défaut est CFQ généralement pour la plupart des systèmes "actuellement".

Pour comparer les planificateurs d'E / S, procédez comme suit:

Lire les tests:

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

Cela vous assurera que vous testez le disque et non les pages de RAM mises en cache, cela videra le cache.

Test d'écriture:

Copiez vos fichiers plusieurs fois simultanément. Une fois les écritures terminées, émettez unsync

Si vous testez les deux, vous voudrez peut-être le faire drop_cacheset appeler synclorsque la copie sera terminée. En plus du planificateur, il existe des paramètres ajustables pour chaque planificateur. Mais, un test rapide serait de changer le planificateur et de réessayer. Si vous avez un bon contrôleur noop, vous lui déchargerez la «planification des E / S» et n'effectuerez aucune planification des données au niveau du système d'exploitation.

Quoi qu'il en soit, cela vaut la peine d'essayer et il suffit d'un echopour le faire reculer.

J'ai résolu le problème en achetant une carte SAS2008. Il se plaint encore un peu dans le journal, mais il ne bloque jamais les E / S disque. J'ai également testé qu'il prend en charge les disques SATA 4 To, tandis que le LSI-SAS1068E ne prend en charge que 2 To.

Comme je retournerai le LSI-SAS1068E au vendeur, je ne pourrai pas essayer d'autres suggestions. Je termine donc la question ici.