ほとんどのOS（VM）が許容できる妥当なストレージフェイルオーバー時間はどれくらいですか？
GlusterFS2ノード2レプリカをセットアップしています。 VMディスクイメージが保存されているOpenStackインスタンスストアとして使用することを計画しています。
私のテストによると、ハイパーバイザーが現在マウントしているGlusterFSノードに障害が発生した場合（デフォルトのGlusterFS設定を使用）、接続がタイムアウトするまでに約45秒かかり、glusterfsクライアントが他のノードにフェイルオーバーします。この45秒間、IO操作がハングします。VMの観点からは、ディスクが応答しなくなることを意味します。
Linuxの場合、ディスクが応答しなくなった場合、しばらくすると（どのくらいの時間がかかるかはわかりません）、カーネルがファイルシステムを読み取り専用として再マウントすることを知っています。
GlusterFSボリュームのnetwork.ping-timeoutの値を下げることもできます。これにより、フェイルオーバー時間が短縮されます。
私の質問は、ほとんどのOSが副作用なしに仮想ディスクの無応答時間を許容できるように、この値をどのくらい設定する必要があるかということです。
もっと正確に言うと、Windows NTFS、FreeBSD UFS/ZFS、およびLinuxext4が許容できるディスクの無応答時間を知りたいです。関連するパラメータは何ですか？ （たとえば、Linuxでは/sys/block/sda/device/timeout）
関連情報：
更新：@ the-wabbitがLinuxとWindowsについて回答しました、FreeBSDのケースも知りたいです
ディスクドライバは通常、構成可能なタイムアウトを超えるまで待機してから、要求された操作のエラーを報告します。
ご存知のとおり、これはLinuxでは/sys/block/<devicename>/device/timeoutであり、デフォルトは 60 30秒。
Windowsは、この構成を グローバル設定TimeoutValue （REG_DWORD）としてHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\に格納しており、デフォルトは60秒です。
アップストリームでエラーが報告されない限り、即時のアクション（FSのro-remountなど）は表示されません。タイムアウトが発生した後でも、通常、エラーハンドラーのアクション（ログ記録、デバイスのリセットなど）が表示されます。エラーは上位層に戻されます。
ただし、全体的な可用性に影響を与える他の影響があることに注意してください。
- アプリケーションまたはシステムサービスは、独自のタイムアウトを実装し、有効期限が切れると例外をスローする場合があります
- リクエストのターンアラウンドが高いサーバーでは、新しいクライアントが新しいリクエストを送信し続け、古いリクエストがストレージの応答を待機しているため、キューがいっぱいになり、メモリが使い果たされます。
- 障害が発生したデバイスにスワップスペースがある場合、すべてのページイン/ページアウト要求が停止し、これらのメモリページで動作するプロセスが効果的にブロックされます。
一般に、時折の負荷スパイクやネットワークグリッチによる早期のフェイルオーバーなしで動作しながら、フェイルオーバー時間をできるだけ短くする必要があります。特定の用途に適した値を決定することは、長期間にわたる試行錯誤の作業です。汎用サーバーVMの場合、実行可能でインフラストラクチャによってサポートされている場合は、10秒の大きさのものを目指します。
FreeBSDにはgeom_mountver（ https://www.freebsd.org/cgi/man.cgi?gmountver ）があり、これを使用してフェイルオーバー時間を許容することができます。 ZFSを使用している場合は、デッドマンタイマーを無効にする必要がある場合があります。 IOが15分以内に完了しない場合（IIRC）、ボックスがパニックになります。