我对 SCSI 还很陌生，实际上什至不确定这是否是正确的论坛。 （我这样做是因为我发现了一些 SCSI 问题:) 所以请随意改进/迁移这个问题。
我正在研究光纤通道传输，并在内部文档中读到，与 TCP 不同，FCP-3 上的 SCSI 不能保证交付，因此我的问题是：
- 这是否意味着SCSI标准/协议本身不可靠？但我认为硬盘曾经非常流行。可靠性问题是如何解决的？
- 同样，SAN 环境中的可靠性如何处理？
答案1
我找到了一篇非正式的文章，做了同样的比较，与我的粗略印象相符。正如 @Sobrique 所提到的，本文还展示了多路径可以在 FC 交换机或大型 SAN 中的一根电缆发生故障时幸存下来。
SCSI 不善待删除的命令。认为 SCSI 不能容忍命令丢失有点误解。可以，只是需要很长时间才能恢复（相对而言）。我见过很多 SCSI 错误，它们会使系统速度减慢。因此最好不要丢失任何 SCSI 命令。
https://datacenteroverlords.com/2011/09/14/fibre-channel-and-ethernet-the-odd- Couple/
看来FCP还没有正式保证交付，但是...如果您阅读维基百科文章，FibreChannel 会指定一定的误码率（可接受/预期）。 TCP 设计用于在链路上运行，与 FibreChannel 相比，它对数据包的关注要少得多。
FibreChannel 还包括流量控制，以避免由于拥塞/缓冲区溢出而丢失数据包。 IP 不会（也不期望底层网络以任何方式这样做）。
例如，谷歌有这个酷纸他们测量 TCP 数据包丢失率平均在 1% 到20%甚至更高。 （他们主张 ISP 使用导致 1% 损失（整形）的技术，而不是导致 20% 以上损失（监管）的技术。这些技术是 IP 网络通常处理拥塞问题的方式）。
我想大多数 SCSI 实现都会重试失败的命令。我不知道它的标准化程度如何 - 我希望可以通过多种方式进行调整。从技术上讲，这也不能保证交付，就像您可以预期 TCP 最终会超时一样（TCP 将放弃并关闭连接）。
答案2
它可能是针对 ServerFault 的一种。
但你说得很对。光纤通道没有与 TCP 相同的保护机制。在这方面，它更像是 UDP（尽管类比有点弱），并且出于许多相同的原因 - 对于某些应用程序，TCP 是糟糕的解决方案，因为这些可靠性机制 - 您的流可能会因重新传输而“停滞”，并且这对近乎实时的应用程序的伤害比丢包更大。当存储 IO 延迟超过 20 毫秒时，您就会开始“受伤”，而这对于 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.