2、UFS基础：UFS协议演进、物理层与链路层、命令队列、逻辑单元与分区
UFS（Universal Flash Storage）并不是“更快的 eMMC”，而是一套面向并行、低功耗与高可靠场景重新设计的存储协议栈。理解 UFS 读写性能，必须先把协议演进、物理链路、命令队列、逻辑单元与分区这五件事串起来看：它们分别决定了“能跑多快”“怎么跑”“谁先跑”“跑到哪里”“哪些数据不能乱跑”。
一、协议演进：从 UFS 2.x 到 UFS 4.x 的能力跃迁
UFS 由 JEDEC 制定，版本演进的核心线索是速率、全双工与能效。UFS 2.0 引入 HS-G2（约 5.8Gbps/lane），UFS 2.1 普及 HS-G3（约 11.6Gbps/lane），UFS 3.0/3.1 进入 HS-G4（约 23.2Gbps/lane），UFS 4.0 则升级到 HS-G5（约 46.4Gbps/lane），并强化了低功耗与多循环队列能力。对调优而言，版本决定了链路理论上限，但实际性能还受设备端 NAND、控制器固件、主机驱动与散热共同约束。
二、物理层与链路层：M-PHY 与 UniPro 的分工
UFS 的物理层采用 M-PHY，链路层采用 UniPro。M-PHY 负责电气信号、Lane 数量与速率档位（HS-G1～HS-G5），支持 PWM 低功耗模式与 HS 高速模式；UniPro 负责链路建立、流量控制、错误恢复与数据包封装。二者共同构成 UFS 的“高速公路与交通规则”。
UFS 通常使用 1 或 2 个 Lane，并支持全双工：读数据与写数据可同时进行。这与 eMMC 的半双工形成本质差异，也是 UFS 在高并发场景下优势明显的原因。调优时需关注链路是否稳定运行在目标速率档位，以及是否因信号完整性或电源噪声降速。
三、命令队列：UFS 并发的核心机制
UFS 采用基于 SCSI 的命令集，并通过 UFS 命令队列（Command Queue）实现多命令并行。主机可同时向设备提交多个命令，设备端按内部调度策略执行，从而提升随机读写与混合负载下的吞吐。UFS 3.0 之后引入多循环队列（Multi-Circular Queue, MCQ），进一步降低主机与设备间的队列管理开销。
调优时，队列深度（Queue Depth）是关键参数。队列过浅，设备内部并行度无法发挥；队列过深，则可能增加延迟与功耗。实际场景中，顺序大文件读写更依赖链路带宽，而随机小 IO 更依赖队列深度与设备端调度能力。
# 查看 UFS 队列与命令统计（示例路径因平台而异）
cat /sys/kernel/debug/ufs/ufs_stats
# 关注字段：
# cmd_queue_depth 当前队列深度
# read_cmds / write_cmds 读写命令计数
# outstanding_reqs 未完成请求数
四、逻辑单元与分区：数据该放在哪里
UFS 设备内部被划分为多个逻辑单元（Logical Unit, LU），每个 LU 有独立的地址空间与属性。典型配置包括：LU0 用于主机命令与配置，LU1/LU2 用于普通数据存储，部分 LU 可配置为 Boot 分区或 RPMB 安全分区。分区机制则进一步把物理 NAND 划分为不同用途区域，如 Boot、RPMB、User Data 等。
| 逻辑单元 / 分区 | 典型用途 | 性能与调优关注点 |
|---|---|---|
| LU0 | 主机命令、描述符、配置 | 访问频率低，但异常时影响初始化与枚举 |
| LU1 / LU2 | 用户数据存储 | 顺序带宽与随机 IOPS 的主要承载区 |
| Boot 分区 | 启动镜像 | 读取延迟敏感，需保证稳定速率 |
| RPMB | 安全存储、防重放 | 写入需鉴权，吞吐低但可靠性要求高 |
五、案例与误区复盘
某移动终端在 UFS 4.0 平台上实测顺序读仅 1.8GB/s，远低于理论值。排查发现：主机驱动未启用 HS-G5，链路协商降到了 HS-G4；同时队列深度被限制为 4，随机写 IOPS 明显偏低。调整链路速率档位并放开队列深度后，顺序读提升到 3.5GB/s 以上，随机写 IOPS 提升约 60%。
复盘要点：先确认物理链路是否运行在目标速率，再检查 UniPro 是否有错误或降速；然后确认命令队列深度与调度策略；最后核对逻辑单元与分区映射是否符合业务预期。只有把“协议演进—物理链路—命令队列—逻辑单元与分区”这条链路打通，后续的读写性能调优才有稳定的分析基础。