Linux VM（Vmwareワークステーションなど）では、以前に動作していたディスクの障害をどのようにシミュレートできますか？テスト中に故障したディスクをシミュレートする方法はありますか？
ディスクに障害が発生した場合（コントローラ、ケーブル、ファームウェアの問題など）の状況が発生しています。明らかにこれは予測可能ではなく、再現性がありません。私は自分のモニタリングをテストして、それが正しく警告することを確認したいと思います。
私は理想的には、書き込みに失敗しても読み込みに成功し、完全に失敗した、つまりscsiインターフェイスがエラーをカーネルに返す状況をシミュレートできるようにしたいと考えています。
ディスクエラーをシミュレートできるレイヤがいくつかあります。単一のユーザー空間プログラムをテストする場合、おそらく最も簡単な方法は、適切な呼び出し（例えば、write()）を挿入して、時々エラーを返させることです。 fiu-runツールを使用してlibfiuフォルトインジェクションライブラリcan do this。
もう1つの方法は、別のデバイスとの間でデータをやりとりすることができるカーネルドライバを使用することですが、途中で障害を注入します。あたかもデバイスをマウントして、障害のあるディスクのようにアプリケーションから使用することができます。 fsdiskドライバがこの例です。
Linuxカーネルにマージされたフォルトインジェクションインフラストラクチャもありますが、おそらくカーネルを再構成して有効にする必要があります。それはDocumentation/fault-injection/fault-injection.txtに記載されています。これはカーネルコードをテストするのに便利です。
SystemTapを使用して、カーネルレベルで障害を注入することもできます。 The SCSI fault injection testおよびKernel Fault injection using SystemTapを参照してください。
SCSIディスクが2.6カーネルと消えるようにする簡単な方法は次のとおり
echo 1 > /sys/bus/scsi/devices/H:B:T:L/delete
（H：B：T：Lはホスト、バス、ターゲット、LUNです）。読取り専用の場合をシミュレートするには、前述のmark4oのような障害注入方法を使用する必要があります。
mark4oの答えに追加するには、Linuxのデバイスマッパーを使用して、故障したデバイスを生成することもできます。
Device Mapper's delay deviceを使用して、同じブロックの読み書きI/Oを異なる下位のデバイスに送信することができます（その名前が示すようにI/Oを遅延させることもできます）。デバイスマッパーのエラーデバイスを使用して、特定のブロックにアクセスしたときに永続的なエラーを生成することができます。この2つを組み合わせることで、常に書き込みが失敗するデバイスを作成できますが、読み取りは常に特定の領域で成功します。
上記は質問Simulate a faulty block device with read errors?（単純なデバイスマッパーの例についてはhttps://stackoverflow.com/a/1871029を参照）に記載されているもののより複雑な例です。
Special File that causes I/O error Unix & Linuxに関する質問には、list of Linux disk fault injection mechanismsもあります。
scsi_debugカーネルモジュールを使用してRAMディスクをシミュレートし、optsおよびevery_nthオプションですべてのSCSIエラーをサポートします。
部門4656上のメディアエラーでこのhttp://sg.danny.cz/sg/sdebug26.html
例を確認してください：あなたはsysfsに経由して、ランタイムでoptsとevery_nthオプションを変更することができ
[[email protected] ~]$ sudo modprobe scsi_debug opts=2 every_nth=1
[[email protected] ~]$ 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
[[email protected] ~]$ 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
を：
echo 2 | sudo tee /sys/bus/pseudo/drivers/scsi_debug/opts
echo 1 | sudo tee /sys/bus/pseudo/drivers/scsi_debug/opts
のLinuxカーネルが提供します「フォールトインジェクション」
と呼ばれる便利な機能セットアップするには10echo 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
1つはまた、メディア・エラー・テストを実行するために、ディスクで提供されているメソッドを使用することができます。 SCSIは、無効なECCを使用してデータを書き込むことによって破損ブロックに使用することができますWRITE LONGコマンドを持っています。 SATAとNVMeにも同様のコマンドがあります。
最も一般的なケース（SATA）の場合は、 - make-bad-sectorでhdparmを使用してそのコマンドを使用することができます。SCSIの場合はsg_write_longを使用でき、NVMeの場合はwrite-uncorオプション。これらのコマンドは、他の注入方法に比べてい
大きな利点は、彼らはまた、ドライブがいっぱいのレイテンシの影響とも再割り当てすることにより、そのセクタへの書き込み時に回復し、場合と同じように振る舞うということです。これには、ドライブにエラーカウンタも含まれます。
欠点は、あなたが同じドライブのために、この、あまりにも多くを行う場合は、そのエラーカウンタが上がると、SMARTは、あなたがその再割り当てテーブルを排気するフラグディスクを悪いことか、ということです。だから、手動テストのためにそれを使用するのですが、あなたは自動テストでそれを実行している場合には、あまりにも頻繁にそれをしません。
おそらく私が見た中で最も集中的に有用な答え... fsdisk'提案 'ため –
Upvoted。 –