読み取り中にHDDのプラグを抜くと、Btrfsで何が起こりますか？

私はLinux（Debian）とBtrfsを初めて使用します。自宅のDIY Nasでテストを開始しました。

セットアップ：-2 WD RED 3TBディスクを備えた中レベルのハードウェア-Debian（最新の安定版）-Btrfs-tools（最新の安定版）-フルディスクraid1セットアップを構成し、数ギガバイトのデータをコピーしました

その後、テストを行い、データを絶えず読み取りながら2台のHDDの1つを取り外しました。驚いたことに、ミラーからの読み取り操作を続行できませんでしたが、代わりに、それについて多くの赤い背景の恐ろしいエラーメッセージが表示されました。

RAID1のようなシステムでは、このようなことを静かに処理してくれると期待しています。これは通常の動作ですか、またはどこかにセットアップのエラーがありますか？

ミラーリングの考え方は、ミラーの片側に障害が発生した場合、もう一方が引き継ぐ必要があることです。理想的な世界では、ミラーの両側が使用可能な場合、読み取りパフォーマンスを向上させるために両側が連携して動作する必要があります。

ただし、ミラーの片側に障害が発生した場合、障害が発生したデバイスへのすべての実行中の読み取りは、おそらく遅延後に失敗します。これは正常で予想されることです。突然コマンドがなくなったデバイスにコマンドが送信され、コマンドに応答できるため、何らかのエラー状態が発生します。ほとんどの場合、カーネルはこれらの失敗をログに記録し、管理者に「何か悪いことが起きた」ことを知らせます。システムは、これらの重要なカーネルイベントをコンソールに出力するように構成できます。

ミラーリングソリューションのリトマステストでは、これらのエラーが実際にユーザースペースレイヤーに伝播し、ユーザーアプリケーションがI / Oエラー（またはさらに悪いことに無効なデータ）を受信するかどうかをテストします。ミラーのセットアップが正常に機能している場合、ミラーの反対側が正常に機能している限り、読み取りに通常より少し時間がかかり、システムがI / Oエラーに関するいくつかの診断を吐き出すという事実を除いて、ユーザースペースアプリケーションは影響を受けません現在利用できないデバイスで発生しています。これらのどちらも、適切に動作するユーザー空間ソフトウェアに大きな影響を与えるべきではありません。

ユーザー空間プロセス（カーネルのBtrfsコードだけでなく）が実験の結果としてI / Oエラーを検出し、少なくとも合理的に一貫して動作を再現できる場合、Btrfsコードのバグに遭遇した可能性があります。 。その場合は、バグレポートを提出することをお勧めします。特にこれがDebianであることを考えると、まずDebianのバグ追跡システムにバグレポートを提出し、それが正当であると感じた場合はカーネル開発者に報告させてください。実行している正確なコマンド、関連するすべての正確なバージョン、エラーメッセージの正確なテキスト、ストレージ設定の正確な説明、その他考えられることなど、できる限り詳細な情報を含めてください。問題の追跡に役立ちます。