web-dev-qa-db-ja.com

mptscsih：ioc0：タスクの中止：成功（rv = 2002）により30秒間フリーズする

ソフトウェアRAID6へのI/Oは、約30秒間フリーズすることが多く、その後すべてが正常に戻ります。

フリーズが終わった後、これは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)

私はエラーをグーグルで調べました、そして誰かが3.0Gbpsではなく1.5Gbpsを使うことを試みることを提案しました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

読み取りまたは書き込み操作のみがある場合、この問題は非常にまれに発生します。1TB問題なく読み取りまたは書き込みできます。両方があると問題が発生するようです読み取りおよび書き込み操作。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

スケジューラーには効果があるので、問題の原因が時間枠内の要求が多すぎることが原因かどうかを考えています。 1秒あたりに送信されるリクエストの数を制限することはできますか？

linux-kerneldriversscsitimeout
12
Ole Tange

SAS2008カードを購入して問題を解決しました。それでも、ログには少し不満がありますが、ディスクI/Oをブロックすることはありません。また、私はそれが4 TB SATAドライブをサポートすることをテストしましたが、LSI-SAS1068Eは2 TBのみをサポートします。

LSI-SAS1068Eを販売者に返却するため、他の提案を試すことはできません。したがって、ここで質問を閉じます。

2
Ole Tange

LSIからのMPTSCSIH-Driverリリースノート は興味深く見えます。

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 バラクーダ3のファームウェア情報TBドライブ。詳細を取得するには、シリアル番号を入力する必要があります。

更新：smartctl -i /dev/sdaaをお試しください。SCSIとSATAでテストし、シリアル番号をそのように取得しました。

5
Nils

I/Oスケジューラを変更してみましたか？

   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です。

I/Oスケジューラを比較するには、次の手順を実行します。

テストを読む：

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

これにより、RAMのキャッシュされたページではなく、ディスクをテストしていることが確認されます。これにより、キャッシュがフラッシュされます。

書き込みテスト：

ファイルを同時に複数回コピーします。書き込みが完了したら、syncを発行します

両方をテストする場合は、drop_cachesし、コピーが完了したらsyncを呼び出します。スケジューラーに加えて、各スケジューラーには調整可能パラメーターがあります。ただし、簡単なテストは、スケジューラを変更して再試行することです。適切なコントローラーがある場合、noopは「I/Oスケジューリング」の負荷を軽減し、OSレベルのデータスケジューリングを実行しません。

とにかく、それは試してみる価値があり、それを元に戻すのにechoをとるだけです。

2
2bc