web-dev-qa-db-ja.com

テスト中に故障したディスクをシミュレートするにはどうすればよいですか？

Linux VM（Vmwareワークステーションなど）で、以前に動作していたディスクの障害をシミュレートするにはどうすればよいですか？

本番環境でディスクに障害が発生する状況が発生しています（おそらくコントローラー、ケーブル、またはファームウェアの問題）。明らかに、これは予測可能または再現可能ではありません。監視をテストして、正しく警告されることを確認したいと思います。

理想的には、書き込みに失敗しても読み取りには成功する状況と、完全な失敗、つまりscsiインターフェイスがカーネルにエラーを報告する状況をシミュレートできるようにしたいと思います。

linuxtestingiodiskscsi
27
MarkR

ディスクエラーをシミュレートできるレイヤーがいくつかあります。単一のユーザースペースプログラムをテストしている場合、おそらく最も簡単なアプローチは、適切な呼び出し（write()など）を挿入し、エラーを返すようにすることです。 libfiu フォールトインジェクションライブラリ これを実行できます その fiu-run ツール。

別のアプローチは、別のデバイスとの間でデータを渡すことができるが、途中で障害を注入できるカーネルドライバーを使用することです。その後、デバイスをマウントして、障害のあるディスクであるかのように任意のアプリケーションから使用できます。 fsdisk ドライバーはこの例です。

Linuxカーネルに統合されたフォールトインジェクションインフラストラクチャもありますが、カーネルを有効にするには、カーネルを再構成する必要があります。 Documentation/fault-injection/fault-injection.txt に記載されています。これは、カーネルコードのテストに役立ちます。

SystemTap を使用して、カーネルレベルで障害を挿入することもできます。 SCSIフォールトインジェクションテスト および SystemTapを使用したカーネルフォールトインジェクション を参照してください。

26
mark4o

Mark4oの答えに追加するために、Linuxのデバイスマッパーを使用して障害のあるデバイスを生成することもできます。

デバイスマッパーの遅延デバイス 同じブロックの読み取りおよび書き込みI/Oを異なる基になるデバイスに送信するために使用できます（名前が示すように、そのI/Oを遅延させることもできます）。デバイスマッパーのエラーデバイスを使用して、特定のブロックにアクセスしたときに永続的なエラーを生成できます。この2つを組み合わせることで、特定の領域で書き込みは常に失敗し、読み取りは常に成功するデバイスを作成できます。

上記は、質問で説明されていることのより複雑な例です 読み取りエラーのある障害のあるブロックデバイスをシミュレートしますか？ （ https://stackoverflow.com/a/1871029 を参照）簡単なデバイスマッパーの例）。

Linuxディスク障害注入メカニズムのリストI/Oエラーの原因となる特殊ファイル UnixとLinuxの質問もあります。

6
Anon

2.6カーネルでSCSIディスクを非表示にする簡単な方法は次のとおりです。

echo 1 > /sys/bus/scsi/devices/H:B:T:L/delete

（H：B：T：Lはホスト、バス、ターゲット、LUNです）。ただし、読み取り専用の場合をシミュレートするには、mark4oが言及したフォールトインジェクション方法を使用する必要があります。

4
caf

ディスクによって提供されるメソッドを使用して、メディアエラーテストを実行することもできます。 SCSIにはWRITELONGコマンドがあり、無効なECCでデータを書き込むことによってブロックを破壊するために使用できます。 SATAとNVMeにも同様のコマンドがあります。

最も一般的なケース（SATA）の場合、hdparmを--make-bad-sectorとともに使用してそのコマンドを使用できます。SCSIの場合はsg_write_longを使用でき、NVMeの場合はwrite-uncorオプションを指定してnvme-cliを使用できます。

これらのコマンドが他のインジェクション方法に勝る大きな利点は、ドライブと同じように動作し、完全なレイテンシーの影響と、再割り当てによるそのセクターへの書き込み時の回復もあることです。これには、ドライブで上昇するエラーカウンターも含まれます。

欠点は、同じドライブに対してこれをやりすぎると、エラーカウンターが上がり、SMARTがディスクに不良のフラグを立てたり、再割り当てテーブルを使い果たしたりする可能性があることです。手動テストですが、自動テストで実行している場合は、あまり頻繁に実行しないでください。

1
Baruch Even

Linuxカーネルは、「フォールトインジェクション」と呼ばれる優れた機能を提供します

echo 1 > /sys/block/vdd/vdd2/make-it-fail

いくつかのオプションを設定するには：

mkdir /debug
mount debugfs /debug -t debugfs
cd /debug/fail_make_request
echo 10 > interval # interval
echo 100 > probability # 100% probability
echo -1 > times # how many times: -1 means no limit

https://lxadm.com/Using_fault_injection

1
brada

scsi_debugカーネルモジュールを使用してRAMディスクをシミュレートでき、optsおよびevery_nthオプションですべてのSCSIエラーをサポートします。

これを確認してください http://sg.danny.cz/sg/sdebug26.html

セクター4656のミディアムエラーの例：

[fge@Gris-Laptop ~]$ Sudo modprobe scsi_debug opts=2 every_nth=1
[fge@Gris-Laptop ~]$ Sudo dd if=/dev/sdb of=/dev/null
dd: error reading ‘/dev/sdb’: Input/output error
4656+0 records in
4656+0 records out
2383872 bytes (2.4 MB) copied, 0.021299 s, 112 MB/s
[fge@Gris-Laptop ~]$ dmesg|tail
[11201.454332] blk_update_request: critical medium error, dev sdb, sector 4656
[11201.456292] sd 5:0:0:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[11201.456299] sd 5:0:0:0: [sdb] Sense Key : Medium Error [current] 
[11201.456303] sd 5:0:0:0: [sdb] Add. Sense: Unrecovered read error
[11201.456308] sd 5:0:0:0: [sdb] CDB: Read(10) 28 00 00 00 12 30 00 00 08 00
[11201.456312] blk_update_request: critical medium error, dev sdb, sector 4656

Sysfsを介して実行時にoptsおよびevery_nthオプションを変更できます。

echo 2 | Sudo tee /sys/bus/pseudo/drivers/scsi_debug/opts
echo 1 | Sudo tee /sys/bus/pseudo/drivers/scsi_debug/opts
0
Gris Ge

低レベルのSCSIユーティリティ（sg3-utils）を使用してドライブを停止することもできます。引き続き照会に応答するため、状態は「実行中」のままですが、読み取りと書き込みは、再開されるまで失敗します。この方法でmdadmを使用してRAIDドライブの削除とリカバリをテストしました。

sg_start --stop /dev/sdb
0
stark