ディスクの障害の追いかけ方
「あなたのデータが消えるとき」ではデータは実はあっさり消えてしまうのだというお話をした。いま流行の「クラウド」に保管すれば、ほとんどの人は、データの保管と保全（バックアップ）を専門家に任せることが出来る。個人でも使えるいろんなサービスが出てきているので、検討してみて欲しい。
今回は、自分がインフラを構築する担当であったり、自社で機材を保守する立場の人であったり、もっと身近に自分の家で使う記憶装置について知りたいという人のために、すこしだけ掘り下げてみたい。
（写真はたまたま私の手元にあったディスクで、このメーカーが特に壊れやすいとかはありません。）
1. ディスクの壊れ方の分類
前回お話しさせて頂いた記事で私が勝手に命名した「半故障」という言葉を使わせていただいた。 「半故障」の定義は、「ドライブの内部で再試行をした結果うまくいってしまい、その時点では障害にならない」状態を言う。例をひとつ挙げると、「書き込み中メディアエラーが発生したが、代替トラックや代替セクターに書き込んだ際にうまくいったので、該当のコマンドは正常終了した」という状態である。[1] 説明の都合上、以下の言葉を使うことにする。
■正常 正常に依頼したコマンドが処理される状態
■半故障 既に説明した、内部で再試行をして何とか成功する状態
■故障 装置から返事がない状態あるいは明示的にエラーが帰ってくる状態
さらに、SCSI のコマンドは OS のドライバー側でも再試行される。
今回、ハードディスク装置 (HDD) でお話をさせていただくが、SCSI で話をしている以上、SSD でも議論は同じである。（SAS, Fibre Channel, iSCSI は SCSIプロトコルを使っている。乱暴な言い方をすれば、どんなケーブルでつないでいるかだけが異なる）
SATAではややコマンドの種類が異なるが、依頼したコマンドと、それに対する応答という考え方は同じなので、SCSIをそれぞれ読み替えてもらえればと思う。
正常
正常な状態とは、SCSI コマンドを投げて、ドライバが期待する時間内に返事があることを言う。
故障
故障の状態とは、依頼したコマンドが正常に処理されない状態だ。「正常」の所で書いたとおり、ドライバは規定の時間内に要求した処理の返事が返ってくることを期待している。この処理が規定の時間に応答が帰ってこないようであれば、いわゆる「タイムアウト」になる。
SCSI のコマンドはすぐに返事が戻ってくるものばかりではないので、時間がかかるものに対しては、”disconnect” と言う操作をおこなう。 この操作が実装された理由というのは、 歴史的なものだ。現在ではあまり見かけない P-SCSI （パラレル SCSI）の実装では、コマンドが流れている間はバスが占有され、他のコマンドを実施することができないからだ[参考文献1]
Disconnect の操作をする代表的なコマンドとしては、READ/WRITE がある。依頼したコマンドの返事を永遠に待つわけにはいかないので、いったん、Disconnectという処理をおこない、次の処理に移る。デバイスは依頼されたコマンドの応答ができる状況になると、Unit Attention （報告することがあります）という通知をおこない、これに基づいて、ドライバは Reconnect 操作をおこない、操作を継続する。Disconnect している間は、ホスト側は他の処理を自由におこなえるので、効率が良いわけだ。ただ、Disconnect したデバイスを永遠に待つわけもいかないので、規定の時間を待つと、時間切れと言うことでエラーにする。これが、有名な “Disconnect timeout” のエラーの正体である。
規定の時間内に返事が返ってこなかったのは、たまたま他のコマンドを処理していて忙しかったということもありうる。従って、実際には、ドライバはエラーにもかかわらず、何度か再試行をおこなう。これは Solaris などでは “retryable” （再試行可能な）SCSI エラーメッセージとして表面化する。 一方で致命的 (fatal) と表現されるのは、ドライブから明確にエラーが返ってくる状態だ。全く応答がなくダンマリになってしまった場合でドライバ内部で再試行を繰り返したがやはりどうしようもないという場合も、fatal と表現される。[2]
半故障
簡単に半故障と申し上げていたのだが、もう少し段階があるのはみなさんが予想されたとおりだ。 ドライブの中で処理してしまえるエラーについては、処理がいったん遅くなるものの、よほど短いタイムアウト値を OS のドライバ側で持たせていない限り、検出されることはない。つまり、「何だか遅いデバイス」として認識される。 前回の記事の時に「そのうち 再試行可能な SCSI エラーを量産することになるので、性能劣化の片棒を担ぐことになる」と申し上げたのは、処理が遅いものだから忙しいときには retryable なエラーを量産することがあるからだ。
障害の追いかけ方
HDD の故障を追いかけるにはどうするか？実例を二つばかり示して、実感して頂こうと思う。
一つ目は、システムログに、エラーが出ている場合だ。以下の例は、Solaris の場合になるが、/var/adm/message というメッセージファイルに sd ドライバというSCSIディスクを扱うドライバーからメッセージが出ている。
例1 SCSI エラー(1) Disconnect Timeout
Dec 15 15:22:28 sampl1 scsi: [ID 243001 kern.warning] WARNING: /pci@0,0/pci10de,375@f/pci1000,3150@0 (mpt1):
Dec 15 15:22:28 sampl1 Disconnected command timeout for target. Vendor='SEAGATE' Product='ST31000NSSUN1.0T' Serial='9KQ5JW34 ' Revision='SU13' SAS=500163600017faf4 Command=0x28 'read(10)' (pkt_time=5 abort_count=0 target=262
Dec 15 15:22:28 sampl1 scsi: [ID 243001 kern.warning] WARNING: /pci@1,0/pci10de,376@e/pci1000,3150@0 (mpt2):
Dec 15 15:22:28 sampl1 Disconnected command timeout for target. Vendor='SEAGATE' Product='ST31000NSSUN1.0T' Serial='9KQ5JW34 ' Revision='SU13' SAS=50016360001f8ce4 Command=0x35 'synchronize_cache' (pkt_time=5 abort_count=0 target=112
Dec 15 15:22:43 sampl1 scsi: [ID 243001 kern.warning] WARNING: /pci@1,0/pci10de,376@e/pci1000,3150@0 (mpt2):
Dec 15 15:22:43 sampl1 mpt_handle_event_sync: IOCStatus=0x8000, IOCLogInfo=0x31110e00, event=0xf
Dec 15 15:22:43 sampl1 scsi: [ID 243001 kern.warning] WARNING: /pci@1,0/pci10de,376@e/pci1000,3150@0 (mpt2):
Dec 15 15:22:43 sampl1 mpt_handle_event: IOCStatus=0x8000, IOCLogInfo=0x31110e00, event=0xfこの例は、古いログで恐縮だが、SAS-1 のドライブからエラーが出ている。Disconnect Command Timeout と言うのは端的に言えば、HBA からコマンドを送り、待っていたが、規定の時間以内にドライブ装置から返事が返ってこなかったと言うことだ。このメッセージには、実行したコマンドは書かれているが、どういう応答だったかまでは書かれていない。
二つ目の例もSCSIのエラーであるが、こちらは「再試行可能(retryable)」なものだ。これは、OSが再度同じリクエストを処理しようとして、成功すれば、何事ごともなかったように処理が継続する場合だ。
// 例2 SCSI エラー (2) retryable
Jul 14 00:33:14 sample2 scsi: [ID 107833 kern.warning] WARNING: /pci@0,600000/pci@0/pci@0/scsi@0/sd@0,0 (sd1):
Jul 14 00:33:14 sample2 Error for Command: read(10) Error Level: Retryable
Jul 14 00:33:14 sample2 scsi: [ID 107833 kern.notice] Requested Block: 67162496 Error Block: 67162514
Jul 14 00:33:14 sample2 scsi: [ID 107833 kern.notice] Vendor: FUJITSU Serial Number: D0C5PA512HAV
Jul 14 00:33:14 sample2 scsi: [ID 107833 kern.notice] Sense Key: Media Error
Jul 14 00:33:14 sample2 scsi: [ID 107833 kern.notice] ASC: 0x11 (read retries exhausted), ASCQ: 0x1, FRU: 0x0
Jul 14 00:33:15 sample2 scsi: [ID 107833 kern.warning] WARNING: /pci@0,600000/pci@0/pci@0/scsi@0/sd@0,0 (sd1):
Jul 14 00:33:15 sample2 Error for Command: read(10) Error Level: Retryable
Jul 14 00:33:15 sample2 scsi: [ID 107833 kern.notice] Requested Block: 67162496 Error Block: 67162506
Jul 14 00:33:15 sample2 scsi: [ID 107833 kern.notice] Vendor: FUJITSU Serial Number: D0C5PA512HAV
Jul 14 00:33:15 sample2 scsi: [ID 107833 kern.notice] Sense Key: Media Error
Jul 14 00:33:15 sample2 scsi: [ID 107833 kern.notice] ASC: 0x11 (read retries exhausted), ASCQ: 0x1, FRU: 0x0
例1 とは直接の関係のないドライブであるが、 Error Level: Retryable とあること、ASC/ASCQ という表記がある。ここから、原因を知ることができる。(この値の調べ方については、後述する）上記の場合は、Block 番号 67162496 に READ(10) というリクエストをかけたところ、ドライブ装置から読み出しの再試行回数の制限を超えてしまったので、エラーとなったことが書かれている。ただし、retryable であるので、再試行可能なエラーである。これだけでは直ちにドライブ交換が必要なわけではないが、あまり数多く出ているようならサポートに電話する内容だと思う。
「半故障」のドライブは、この再試行可能なエラーが数多く出ることが多い。
ASC/ASCQを見てみる
次に、FMA のメッセージをお見せしようと思う。FMA は何だかよくわからないメッセージが多いという方が多いのだが、ことディスクについては場合によっては、「何の SCSI コマンドが、どういうエラーを出したか」まで明確にすることができて、実はありがたい。ちょっとした見方のコツを知っている必要があるだけである。
//例3）FMAのエラー（概要）
-bash-4.1$ fmdump errlog | head
TIME CLASS
Aug 28 2015 08:31:46 ereport.io.scsi.cmd.disk.dev.uderr
Aug 28 2015 08:31:46 ereport.io.scsi.cmd.disk.dev.rqs.derr
Aug 28 2015 08:31:46 ereport.io.scsi.cmd.disk.recovered
Aug 28 2015 08:31:47 ereport.io.scsi.cmd.disk.dev.rqs.derr
Aug 28 2015 08:31:47 ereport.io.scsi.cmd.disk.dev.rqs.derr
Aug 28 2015 08:31:47 ereport.io.scsi.cmd.disk.recovered
Aug 28 2015 08:31:47 ereport.io.scsi.cmd.disk.dev.rqs.derr
Aug 28 2015 08:31:47 ereport.io.scsi.cmd.disk.dev.rqs.derr
Aug 28 2015 08:31:47 ereport.io.scsi.cmd.disk.recoveredこの中で、ディスクがなぜ故障したのだろうと思ったときに注目したいのは、ereport.io.scsi.cmd.disk.dev.rqs.derr というクラスだ。これは、送った SCSI コマンドがエラーになった場合に、出力される。report.io.scsi.cmd.disk.dev.uderr も同様だ。ここでは、解説のために、ereport.io.scsi.cmd.disk.dev.rqs.derr の詳細を見ることにする。
例4）FMAのエラー（詳細）
-bash-4.1$ fmdump -t '03/16/16 00:00:00' -T '03/16/16 23:59:59' -c ereport.io.scsi.cmd.disk.dev.rqs.derr -eV ./errlog | head -30
TIME CLASS
Mar 16 2016 16:08:40.085036300 ereport.io.scsi.cmd.disk.dev.rqs.derr
nvlist version: 0
class = ereport.io.scsi.cmd.disk.dev.rqs.derr
ena = 0x1a029fc647801001
detector = (embedded nvlist)
nvlist version: 0
version = 0x0
scheme = dev
cna_dev = 0x56e9800d000007e3
device-path = /pci@35,0/pci8086,e04@2/pci11f8,8018@0/iport@f/disk@w5000cca05cc327b5,0
devid = id1,sd@n5000cca05cc327b4
(end detector)
devid = id1,sd@n5000cca05cc327b4
driver-assessment = retry
op-code = 0x2a
cdb = 0x2a 0x0 0x4 0x0 0x4f 0x18 0x0 0x0 0x28 0x0
pkt-reason = 0x0
pkt-state = 0x3f
pkt-stats = 0x0
stat-code = 0x2
key = 0x6
asc = 0x29
ascq = 0x0
sense-data = 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0x18 0x0 0x0 0x0 0x0 0x2a 0x1 0x1c 0x0 0x0 0x0 0x0 0x0
__ttl = 0x1
__tod = 0x56e98508 0x5118d0cこの中で注目する値は、4つ。
ひとつ目は op-code。これは、送られた SCSI のコマンドだ。 SCSI のいい方では CDB (Command Descriptor Block) と呼んだりする。
ふたつ目は key。ここは Sense Key と呼ばれるものだが、通常 0x6 (Unit Attention) が入っている。
３つめと 4 つめは組み合わせて読み、ASC とASCQ とよばれる値だ。
それぞれ、SCSI の規格として、t10.org の文書に説明があるが、便利な一覧表が用意されている。
・ Opcode/CDB http://t10.org/lists/op-num.txt
・ Sense key http://t10.org/lists/2sensekey.htm
・ ASC/ASCQ http://t10.org/lists/asc-num.txt
エラーの中で、op-code とあるのは SCSI のコマンドである。
今回の場合は 0x2a WRITE(10) ということなので、10バイトで表現される WRITE 要求であることがわかる。
asc/ascq は一組になって、エラーを表現する。
一つ注意しなければいけないのは、asc/ascq には vendor unique code というものが許されていて、t10.org のこのリストには載っていないものがある。この場合は、該当の会社の SCSI Interface Reference Manual を参照して、意味を調べる必要がある。[4]
今回の場合は、0x29/0x0 であるので、POWER ON RESET であって、電源投入直後か、あるいは、ドライブが返事をしないので、ホスト側からリセットを要求した結果だと考えられる。
同様のメッセージがあまり続いているようであれば、ドライブが何らかの理由で返答をしなくなっており、交換する候補となる。
参考文献
[参考文献1] 絶版になってしまったが 、「SCSI‐2詳細解説―最新SCSI規格とコマンド・リファレンス (規格解説シリーズ)」は私もよく参照させていただいた。残念ながら、SCSI-3 や SAS については日本語でまとまった書籍がないのが現状である。 現在無料で見ることができるのは、t10.org の SCSI-3 の規約の working draft である。http://t10.org/scsi-3.htm
いいなと思ったら応援しよう！
