大多數作業系統 (VM) 可以容忍的合理儲存故障轉移時間是多少？
我有一個 GlusterFS 2 節點 2 副本設置。我打算將它用作儲存 VM 磁碟映像的 OpenStack 實例儲存。
根據我的測試，如果虛擬機管理程序目前掛載的 GlusterFS 節點出現故障，（使用預設的 GlusterFS 設置）連接超時大約需要 45 秒，並且 Glusterfs 客戶端故障轉移到另一個節點。在這 45 秒內，IO 操作將掛起，從 VM 的角度來看，這意味著磁碟變得無響應。
我知道對於 Linux，如果磁碟變得無響應，一段時間後（我不確定多長時間）核心會將文件系統重新掛載為只讀。
我還可以降低 GlusterFS 卷的值
network.ping-timeout，這將減少故障轉移時間。我的問題是，我應該將這個值設置多少才能使大多數作業系統能夠容忍虛擬磁碟的無響應時間而沒有副作用？
更準確地說，我想知道 Windows NTFS、FreeBSD UFS/ZFS 和 Linux ext4 可以容忍的磁槃無響應時間。涉及的參數有哪些？（例如，
/sys/block/sda/device/timeout在 Linux 上）相關資訊：
- 如何降低 Gluster FS 宕機超時/減少宕機影響？
- http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009465
更新：@the-wabbit 已經回答了 Linux 和 Windows，我也想知道 FreeBSD 的案例
磁碟驅動程序通常會等到超過可配置的超時時間，然後才會報告請求的操作錯誤。
正如您所發現的，這是
/sys/block/<devicename>/device/timeout在 Linux 中，預設為60 30 秒。Windows 將此配置儲存為全域設置
TimeoutValue(REG_DWORD)，HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\預設值為 60 秒。只要上游沒有報告錯誤，您將不會立即看到任何操作（例如 FS 的 ro-remount），即使在超時結束後，您通常也會看到更多錯誤處理程序操作（記錄、重置設備等）之前錯誤被傳遞回上層。
但請注意，還有其他影響整體可用性的影響。
- 應用程序或系統服務可能會實現自己的超時並在到期時拋出異常
- 在請求周轉率高的伺服器上，您會看到隊列已滿，記憶體耗盡，因為新客戶端不斷送出新請求，而舊請求仍在等待儲存響應。
- 如果您碰巧在故障設備上有交換空間，所有頁面輸入/頁面輸出請求都將停止，從而有效地阻止在這些記憶體頁面上工作的程序。
通常，您會希望盡可能縮短故障轉移時間，同時仍然可以執行，而不會由於偶爾的負載峰值或網路故障而過早地進行故障轉移。為您的特定使用案例確定正確的值是在長時間的執行中反複試驗的工作。對於通用伺服器虛擬機，如果可行並得到您的基礎架構支持，我的目標是 10 秒左右。