mptscsih: ioc0: task abort: SUCCESS (rv=2002) 导致 30 秒冻结

Question

我的软件 RAID6 的 I/O 经常冻结大约 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.5Gbps 而不是 3.0Gbps。使用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

那没有帮助。

我尝试将“设备缺少 I/O 延迟”更改为 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 TB。这个问题似乎是有到出现两种读取和写入操作。如果您写入的文件小于条带大小并且尚未缓存条带（在这种情况下，必须读取条带以计算新的校验和），则会在 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

将调度程序更改为cfq120-300 秒后会导致问题出现。

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

编辑2

由于调度程序有影响，我在想问题是否是由时间范围内的请求过多引起的。我可以以某种方式限制每秒发送的请求数吗？

Answer 1

LSI的MPTSCSIH-Driver Release Notes看起来很有趣。

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)

使用此链接获取有关 Barracuda 3 TB 硬盘的希捷固件信息。您必须输入序列号才能获得详细信息。

更新：试一试smartctl -i /dev/sdaa我刚刚在 SCSI 和 SATA 上测试了它并以这种方式获得了序列号。

Answer 2

我通过购买SAS2008卡解决了这个问题。它仍然在日志中抱怨一点，但它永远不会阻塞磁盘 I/O。我还测试过它支持 4 TB SATA 驱动器，而 LSI-SAS1068E 仅支持 2 TB。

由于我将把 LSI-SAS1068E 退还给卖家，因此我无法尝试其他建议。因此我在这里结束这个问题。