UFS使用SCSI指令，为啥不使用NVMe的指令呢？

这问题问得挺实在的！确实，现在NVMe这么火，大家对它趋之若鹜，但很多文件系统（比如咱们熟悉的UFS）还是在用SCSI指令，这背后是有历史、有技术，也有一些现实考量的。咱们就掰开了揉碎了聊聊这个事儿。

1. UFS是个“老资格”文件系统，它的诞生背景和SCSI的渊源

首先得明白，UFS（Unix File System）不是今天才出现的。它在很早的时候就有了，是Unix世界里非常核心的文件系统之一。你可以把它想象成一位在IT界打拼多年的前辈。

而SCSI（Small Computer System Interface）呢，也是个老江湖。它是一种非常通用、成熟的接口标准，最早是为连接各种外部设备（比如硬盘、磁带机、扫描仪等）设计的。SCSI指令集也非常丰富，能够控制各种存储设备进行数据传输、设备管理等操作。

UFS在设计之初，为了能够与当时主流的存储设备进行交互，自然就采用了SCSI作为它和硬件之间的“沟通语言”。这就像你学一门外语，最开始接触的是英语，因为当时英语是国际通用语言，很多技术文档和设备都是用英语来描述和控制的。

2. SCSI的“稳定压舱石”地位和UFS的适配性

SCSI指令集之所以能被广泛接受并沿用至今，很大程度上是因为它的：

通用性强： SCSI的设计非常灵活，它不特指某一种存储介质，理论上可以连接任何符合SCSI标准的设备。这种通用性使得操作系统和文件系统不必为每一种新的存储技术去重新设计一套接口。
功能全面： SCSI指令集包含了诸如读、写、擦除、格式化、查询设备状态、错误处理等一系列丰富的功能。这使得文件系统能够精细地控制存储设备，执行各种复杂的操作。
成熟稳定： 作为一项存在多年的技术，SCSI已经经历了无数次的迭代和优化，其稳定性和可靠性得到了充分验证。这对于需要长时间稳定运行的文件系统来说，是至关重要的考量。

UFS作为一个文件系统，它的核心职责是管理数据，组织文件，而具体的读写操作，它会把这些任务“委派”给底层的存储驱动和接口。SCSI提供的这些丰富且成熟的指令，足以让UFS有效地完成它的工作。UFS并不需要知道硬盘内部是怎么工作的，它只需要知道如何通过SCSI指令告诉硬盘“把这块数据写到这里”或者“从那里读出数据”。

3. NVMe的出现：新的规则，新的挑战

NVMe（NonVolatile Memory Express）是为闪存存储（特别是SSD）量身定制的接口协议。它的出现，可以说是存储界的一次“革新”。与传统的SATA接口和SCSI协议相比，NVMe有几个颠覆性的优势：

直接连接到CPU： NVMe通过PCIe总线直接与CPU连接，绕过了SATA控制器等中间环节，大大降低了延迟。
多队列深度和并发性： NVMe支持更多的命令队列和更大的队列深度，能够并行处理大量IO请求，非常适合现代多核处理器的并发能力。
更精简的命令集： NVMe的指令集是为了SSD的特性而设计的，相比SCSI更加精简高效，减少了CPU的开销。

4. 为啥UFS不直接迁移到NVMe指令？这里的顾虑和成本

虽然NVMe听起来无比美好，但让UFS这样历史悠久的文件系统“一夜之间”改用NVMe指令，并不是一件简单的事，而且也并非总是必要。原因有几个方面：

技术栈的兼容性和迁移成本：
底层驱动层： 文件系统（如UFS）的实现依赖于底层的存储驱动程序。如果UFS要使用NVMe指令，就需要文件系统层和NVMe驱动层之间建立新的、直接的交互机制。这意味着需要修改UFS的核心代码，使其能够理解并生成NVMe指令，而不是继续通过SCSI层去间接发送。
复杂性增加： SCSI指令集虽然庞大，但它屏蔽了很多硬件的细节。而NVMe更“贴近”硬件，文件系统如果直接使用NVMe指令，就需要了解更多SSD的内部工作原理，这无疑会增加UFS的实现复杂性。
巨大的改造成本： UFS作为一个成熟的文件系统，已经被广泛应用于各种操作系统和硬件平台。对其进行大规模的重构，使其完全适配NVMe指令，意味着巨大的开发、测试和维护成本。这包括代码重写、性能调优、兼容性验证等等。

并非所有存储都只用NVMe：
虽然NVMe SSD是趋势，但市场上仍然存在使用SATA接口的SSD，甚至HDD（机械硬盘）还在某些场景下有优势。如果UFS完全放弃SCSI指令，那么它将无法在这些非NVMe设备上运行，这会大大限制其适用范围。SCSI的通用性在这里就显得尤为重要。

SCSI层已经封装了NVMe：
事实上，操作系统和存储栈的设计已经考虑到了这个问题。现在很多Linux发行版中，存在一个叫做`nvmescsi`（或者类似的）的兼容层。这个层的作用是，当文件系统发送SCSI指令给存储设备时，如果这个设备支持NVMe，那么这个兼容层会将SCSI指令“翻译”成等效的NVMe指令，然后通过PCIe总线发送给SSD。
这样一来，文件系统（如UFS）就无需改变，它依然使用它熟悉的SCSI指令，而底层的驱动和兼容层则负责将其高效地转换为NVMe指令。这就像你习惯用中文和老朋友聊天，而老朋友虽然懂日文，但你可以让他请个翻译，把你的中文转成日文给日本的朋友听。文件系统不用学新语言，也能让NVMe SSD跑起来。

性能瓶颈的来源多样：
文件系统的性能瓶颈，不仅仅在于存储接口的指令集。磁盘I/O的延迟还受到很多其他因素的影响，比如文件系统的内部结构、内存缓存、CPU处理能力、调度算法等等。
即使文件系统直接使用NVMe指令，如果文件系统自身的某些设计存在效率问题，那么性能提升也可能有限。而通过SCSI层间接通信，如果兼容层做得好，其性能损失可能在可接受范围内，尤其是在很多非极致性能要求的场景下。

5. 未来趋势和可能性

当然，这并不意味着UFS永远不会拥抱NVMe。随着技术的发展，我们可能会看到：

更现代的文件系统原生支持NVMe： 像Btrfs、XFS、ZFS等较新的文件系统，在设计时就更多地考虑了现代存储的特性，它们与NVMe的结合会更紧密，甚至可能有一些针对NVMe的优化。
特定场景下的UFS优化： 在某些对性能要求极高的场景，可能会出现对UFS进行深度改造，使其能够直接利用NVMe特性的版本，但这通常会伴随额外的维护成本和兼容性问题。
抽象层的进一步演进： 存储栈的抽象层会不断优化，可能提供更高效的方式让文件系统和NVMe设备交互，而不需要文件系统去直接理解NVMe指令集的所有细节。

总结一下：

UFS使用SCSI指令，并不是因为它不知道NVMe的存在或者不懂NVMe的好处。主要是因为：

历史包袱和兼容性： UFS是一个老资格，SCSI是它早期的“指定语言”，并且非常通用，支持各种存储设备。
迁移成本和复杂性： 直接让UFS适配NVMe指令需要巨大的技术改造和投入。
现有的兼容层： 操作系统已经通过兼容层（如`nvmescsi`）实现了文件系统与NVMe设备的“间接沟通”，让UFS在不改变自身的情况下也能享受到NVMe的优势。
性能瓶颈的多样性： 文件系统性能受多种因素影响，接口指令只是其中一环。

所以，你可以理解为，这是一种在保持现有系统稳定性和兼容性的前提下，逐步拥抱新技术的一种务实的选择。就像我们可能更愿意在新买的手机上用最新的操作系统，但家里老旧的家电，我们还是习惯用它原有的遥控器，而不是期望它也学会最新的智能家居协议。

应该只是技术发展的路线问题。

UFS来自于EMMC，EMMC最早就是用SCSI的，所以就这样延续下来了。

NVMe属于全新设计的硬件体系，所以不用SCSI也是正常的。