SCSI 和 SAN 如何實現可靠性？
我對 SCSI 很陌生，實際上甚至不確定這是否是正確的論壇。（我這樣做是因為我發現了一些 SCSI 問題 :) 所以請隨時改進/遷移這個問題。
我正在玩光纖通道傳輸，並在內部文件中讀到與 TCP 不同，FCP-3 上的 SCSI 不能保證傳遞，因此我的問題是：
- 這是否意味著 SCSI 標準/協議本身不可靠？但我認為它曾經非常流行於硬碟。可靠性問題是如何解決的？
- 同樣，在 SAN 環境中如何處理可靠性？
它可能是 ServerFault 之一。
但你說得很對。光纖通道沒有與 TCP 相同的保護機制。在這方面它更像 UDP（儘管這有點弱的類比）並且出於許多相同的原因 - 對於某些應用程序，由於這些可靠性機制，TCP 是不好的解決方案 - 您的流可能會“停止”重新傳輸，並且這比丟棄的數據包對近實時應用程序的傷害更大。當您超過大約 20 毫秒時，您開始“傷害”儲存 IO 延遲，而 TCP 沒有足夠的時間真正做到這一點。
FCP 發生的事情是端點上的 SCSI 驅動程序處理可靠性，因為作為其中的一部分，它還可以進行負載平衡。通常，您不會單獨連接光纖，而是使用具有雙獨立儲存路徑的雙 HBA。
因此，您的驅動程序可以隨心所欲地路由數據包（有些比其他的更智能 - 現在大多數都進行多路徑處理，但有些則進行了一些非常聰明的自適應多路徑處理），並跟踪哪些 IO 已被確認或未確認。作業系統可以在適當的情況下對 IO 進行排隊，或者……好吧，如果它認為這是一個壞主意，則不是。實際上，無論如何它都將其作為正常文件系統記憶體機制的一部分。
這就是為什麼，例如
open有O_DIRECT選項：O_DIRECT (since Linux 2.4.10) Try to minimize cache effects of the I/O to and from this file. In general this will degrade performance, but it is useful in special situations, such as when applications do their own caching. File I/O is done directly to/from user- space buffers. The O_DIRECT flag on its own makes an effort to transfer data synchronously, but does not give the guarantees of the O_SYNC flag that data and necessary metadata are transferred. To guarantee synchronous I/O, O_SYNC must be used in addition to O_DIRECT. See NOTES below for further discussion.
我發現一篇非正式的文章進行了相同的比較，這與我的粗略印象相符。正如@Sobrique 所提到的，該文章還展示了多路徑以在 FC 交換機或其中一根電纜進入大型 SAN 的故障中倖免於難。
SCSI 不接受丟棄的命令。SCSI 不能容忍失去的命令是一種誤解。可以，只是需要很長時間才能恢復（相對而言）。我見過很多 SCSI 錯誤，它們會使系統慢下來。所以最好不要失去任何 SCSI 命令。
https://datacenteroverlords.com/2011/09/14/fibre-channel-and-ethernet-the-odd-couple/
聽起來 FCP 並沒有正式保證傳遞，但是……如果您閱讀 Wikipedia 文章，FibreChannel 指定了一定的誤碼率（如可接受/預期的那樣）。TCP 設計用於在與 FibreChannel 相比對數據包的關注程度低得多的鏈路上執行。
FibreChannel 還包括流量控制，以避免由於擁塞/溢出緩衝區而丟棄數據包。IP 沒有（並且不希望底層網路以任何方式這樣做）。
例如，Google有這篇很酷的論文，他們測量了平均在 1% 到20% 甚至更高的 TCP 封包遺失率。（他們主張 ISP 使用導致 1% 損失（整形）而不是 20%+ 損失（監管）的技術。這些技術是 IP 網路通常處理擁塞問題的方式）。
我猜大多數 SCSI 實現都會重試失敗的命令。我不知道它有多標準化——我希望它可以以各種方式進行調整。從技術上講，這也不能保證傳遞，就像您可以預期 TCP 最終會超時（TCP 會放棄並關閉連接）一樣。