UFS主机设备交互

1 概述

本小节描述了几个旨在提高性能和/或可靠性的 UFS 特性。其中一些与逻辑单元队列中存在的命令直接相关（例如，LU 间优先级、系统数据标签、上下文管理），另一些与设备状态相关（例如，后台操作、动态设备容量），或专注于可靠性（例如，数据可靠性、实时时钟信息）。

2 适用设备

本文描述的所有特性都应在 UFS 设备上实现。这些特性的实现程度取决于设备制造商。预计实现不佳将导致设备性能或可靠性降低，以及在低功耗模式下的最大功耗升高。

3 命令队列：LU 间优先级 (Inter-LU Priority)

本节概述了设备内队列如何相互交互。UFS 设备可以有许多不同的实现。例如，它可以实现为单线程或多线程处理器。为了使 UFS 规范实现无关，本节概述了一个参数，允许主机向设备传达其优先级，以便设备在执行来自主机的命令时可以考虑这一点。

在多个队列由单个执行单元提供服务的情况下，主机需要将所有队列指定为具有相同优先级，或将单个队列指定为具有更高优先级。应定义一个参数值，以允许主机将队列指定为高优先级或无优先级。在队列被指定为具有更高优先级的情况下，每当命令进入高优先级队列时，它将尽快执行，从而导致来自其他队列的命令被挂起。

主机可能希望利用此特性的一个例子是，当主机分配一个逻辑单元作为代码执行单元，另一个单元作为大容量存储单元时。在此示例中，代码执行优先于大容量存储传输，因此主机会将与代码逻辑单元关联的参数位设置为高优先级，而将剩余队列保留为较低优先级。

逻辑单元支持两级队列优先级：

1. 高优先级 – 用于具有高优先级请求的逻辑单元。发送到此逻辑单元的任何命令将比发送到具有较低优先级的逻辑单元的命令具有更高的优先级。例如，在服务需求分页 (demand-paging) 应用程序时，读取命令将具有此优先级。
2. 无优先级 – 用于所有不属于优先级 #1 的常规逻辑单元。

除了主机显式发出的命令执行外，设备可能会执行用于设备维护的后台操作。通常，这些操作的优先级远低于主机发送的命令，并后台操作模式中描述的特定方法实现。

设备描述符中的 bHighPriorityLUN 参数应设置为配置哪个逻辑单元具有更高优先级的命令队列。

4 后台操作模式 

4.1 简介

托管设备需要时间来执行管理任务。后台操作模式授予设备时间来执行与这些闪存管理任务相关的命令。闪存管理操作可能包括但不限于：损耗均衡 (wear leveling)、坏块管理 (bad block management)、擦除 (wipe) 和垃圾回收 (garbage collection)。在后台操作期间完成的操作由设备制造商决定，不在 UFS 规范范围内。

4.2 目的

• 性能改进：通过允许设备将因主机启动的操作而产生的设备管理活动推迟到主机未使用设备的时段，从而提高设备对主机命令的响应能力。

• 主机电源管理：允许主机控制设备何时使用电源执行管理活动。主机将更了解系统消耗的功率，并可以在使用系统电源和节约电源之间做出适当的权衡。

4.3 后台操作状态

设备使用异常事件机制 (Exception Event mechanism) 向主机发出信号，表明设备需要执行后台操作，特别是使用 wExceptionEventStatus 中的 URGENT_BKOPS 位。

• ‘0’：不需要立即执行后台操作（对应于无操作或非关键操作）
• ‘1’：需要立即执行后台操作（对应于性能受到影响或关键操作）

当主机检测到执行后台操作的请求（URGENT_BKOPS 设置为 1）时，它可以读取 bBackgroundOpStatus 属性以了解需求级别，如下所示：

• 00h：不需要操作
• 01h：有待处理的操作（非关键）
• 02h：有待处理的操作（性能正受到影响）
• 03h：有待处理的操作（关键）

如果 bBackgroundOpStatus 设置为 00h 或 01h，则 URGENT_BKOPS 位设置为零，否则设置为 1。

4.4 操作启动

没有显式命令来启动后台操作。一个模式启用位 (mode enable bit) 指示是否允许设备执行后台操作。如果后台操作启用位被设置并且设备处于活动 (Active) 电源模式或空闲 (Idle) 电源模式，则允许设备执行任何内部操作。

4.5 电源故障

如果后台操作期间发生电源故障，设备有责任确保设备中的数据不被损坏。

5 断电通知 (Power Off Notification)

UFS 主机将通过请求设备进入 UFS-PowerDown 电源模式来通知设备它将为设备断电。这将给设备时间干净利落地完成任何正在进行的操作。当设备准备好断电（即设备已进入 UFS-PowerDown 电源模式）时，设备将响应主机。然后主机可以关闭设备电源，而不会冒数据丢失的风险。

6 动态设备容量 (Dynamic Device Capacity)

常见的存储设备假设容量是固定的。随着设备老化并接近其使用寿命结束，这带来了一个问题。当设备的某些块变得太旧而无法可靠使用时，备用块 (spare blocks) 会被重新分配来替换它们。设备包含一些备用块用于此目的，也用于一些维护操作。然而，当所有备用块都被消耗完时，设备就无法再满足其固定容量定义，并且会停止工作（有些变为只读，有些则完全停止响应）。

使主机能够在设备使用寿命结束时继续运行的简单解决方案是允许容量是动态的。如果允许设备减少其报告的容量，它可以将用于存储数据的块重新分配为新的备用块，以补偿老化。为了支持这一点，设备需要向主机报告每个逻辑单元还需要多少备用块，然后主机需要释放一些已使用的块，让设备将它们重新分配为备用块。

设备可以实现按逻辑单元划分的备用块资源管理策略，为每个逻辑单元分配固定数量的备用块；或按内存类型划分，为所有具有相同内存类型 (bMemoryType) 的逻辑单元分配固定数量的备用块。

几何描述符 (Geometry Descriptor) 中的 bDynamicCapacityResourcePolicy 参数指示实现了哪种备用块资源管理策略。

6.1 实现

6.1.1 初始设备要求

只有支持精简配置 (thin provisioning) 和逻辑块配置管理 (logical block provisioning management) 功能的逻辑单元才能参与动态设备容量过程。

每个逻辑单元的单元描述符包含以下两个参数：qLogicalBlockCount （等于逻辑单元中可寻址逻辑块的总数）和 qPhyMemResourceCount（等于逻辑单元中可用的总物理内存资源）

UFS 要求在设备首次配置时，物理内存资源池中应有足够的资源来支持 READ CAPACITY 中报告的逻辑可寻址内存空间。

动态设备容量特性不涉及以下逻辑单元：RPMB 众所周知逻辑单元、上电写保护逻辑单元（与 fPowerOnWPEn 标志值无关）、永久写保护逻辑单元（与 fPermanentWPEn 标志值无关），或配置为启动逻辑单元的逻辑单元（Boot LUN ID = 01h 或 02h，与 bBootLunEn 值无关）。

6.1.2 物理内存资源状态机

图 13.5 显示了物理内存资源的状态机。除了在逻辑块配置状态机中也定义的“已映射”(Mapped) 状态和“已解除分配”(Deallocated) 状态外，还有“已从资源池中移除”(Removed from the Resource Pool) 状态。

1. 写操作：来自资源池的物理内存资源被映射到包含有效数据的 LBA。

2. 用于擦除/丢弃的 UNMAP 操作：

   a) 物理内存资源从 LBA 解除映射（解除分配）并返回到资源池。

   b) 未映射的物理内存资源中的残留数据无效。

3. 先前将 fPhyResourceRemoval 标志设置为 1 的设备重新初始化会导致一些物理内存资源从服务于逻辑地址空间的资源池中移除。转换后，UFS 设备更新 qPhyMemResourceCount 以指示每个逻辑单元资源池中剩余的物理内存资源量。

7 数据可靠性 (Data Reliability)

UFS 主机能够定义每个逻辑单元在正常运行期间和电源故障期间的数据可靠性级别。

为 UFS 定义的数据可靠性有两个组成部分。第一个组成部分处理当前正在写入的数据，第二个组成部分处理先前已存储在介质中的数据。

第一个组成部分，也称为可靠写入 (Reliable Write)，意味着如果设备在向介质执行写入操作期间断电（在执行 SCSI 写入命令、主机启动将数据刷新到介质等时），当设备从电源故障恢复时，受操作影响的范围内的数据将是旧数据或新写入的数据。

保留旧数据或新数据对于文件系统在断电后恢复非常重要。文件系统可以将其结构分段并用 CRC 或等效机制签名。设备确保足够大的数据粒度是真实的（无论是旧副本还是新副本），以确保文件系统可以验证或使这些段无效。

旧数据和新数据的解析应对齐到逻辑块大小。图 13.6 显示了主机在具有 4 Kbyte 逻辑块大小的逻辑单元中执行 32 Kbyte 写入操作期间发生电源故障后恢复时可能看到的一些场景。

对于 RPMB 众所周知逻辑单元，数据可靠性粒度在普通 RPMB 模式下应等于 bRPMB_ReadWriteSize × 256 字节，在高级 RPMB 模式下等于 bRPMB_ReadWriteSize × 4K 字节。bRPMB_ReadWriteSize 值应根据 RPMB 配置更改为适当的值。

第二个组成部分，也称为数据可靠性 (Data Reliability)，允许主机定义应用于设备上现有数据的保护级别。在用于实现 UFS 设备的某些技术中，设备可以选择在电源故障期间牺牲设备上的一些现有数据，以提供更好的写入性能。根据终端设备的应用，主机可以按逻辑单元选择该逻辑单元中的数据在电源故障期间是否应受到保护（这可能影响性能），或者选择设备性能但承担电源故障期间丢失数据的风险。

可以在系统集成期间配置设备时为每个逻辑单元设置数据可靠性特性。

具体来说，如果启用了数据可靠性，逻辑单元将执行可靠写入操作，并且已经存储在介质中的数据不会因在向介质执行写入操作期间发生的电源故障而损坏。

数据可靠性特性仅对逻辑单元可配置，对众所周知逻辑单元不可配置。

RPMB 众所周知逻辑单元将自动选择数据可靠性。

8 实时时钟信息 (Real-Time Clock Information)

向存储设备提供实时时钟 (RTC) 信息可能对设备内部维护操作有用（RTC 内部操作的执行不受 fBackgroundOpsEn 标志值的影响）。

主机可以提供绝对时间（如果可用）或相对时间信息。此功能提供了一种机制，供主机更新绝对时间或相对时间。

自上次 RTC 信息更新以来，当 wPeriodicRTCUpdate 指定的时间已过时，主机发送 RTC 信息。如果设备在周期到期时未上电或处于睡眠状态，主机将其唤醒并更新 RTC 信息。

建议在从 UFS-Sleep、UFS-DeepSleep 或 UFS-PowerDown 电源模式转换到活动 (Active) 电源模式后提供 RTC 信息。

通过写入 dSecondsPassed 属性来更新 RTC 信息。

当设备忙于处理 RTC 更新事件和相关后台操作时，设备可以保持 fBusyRTC 标志设置为 1。

设备可能会在收到 RTC 更新后在后台执行操作。为了允许这些后台操作优化效率，建议主机避免向设备发送除查询请求 (Query Request) 之外的命令，并在 fBusyRTC 标志设置为 1 时保持设备通电并处于活动电源模式。设备在此期间可能消耗活动功率。因此，建议在系统通常空闲且没有特定功耗限制的时间（例如，夜间电池充电时）更新 RTC。

9 时间戳信息 (Timestamp Information)

向存储设备提供时间戳信息 (qTimestamp) 对于同步设备错误日志（通过 READ BUFFER 命令检索）和主机错误日志可能有用。

此功能提供了一种机制，供主机向设备提供时间标签（时间戳）；设备可以将此信息存储在非易失性存储器中，并在事件发生时用于设备错误日志中的时间标记。

如果设备不处于活动状态，设备可能不知道自上次活动以来经过了多少时间。因此，建议主机在设备上电复位 / 硬件复位或切换到活动状态时（使用 Start Stop Unit 命令）设置设备的 qTimestamp。

10 上下文管理 (Context Management)

为了更好地区分大型顺序操作和小型随机操作并改进多任务支持，可以将上下文 (context) 与读或写命令组相关联。将一组命令与共享上下文相关联允许设备优化数据处理。

上下文可以看作是一个活动会话 (active session)，配置用于特定的读/写模式（例如，某种粒度的顺序访问）。多个读或写命令与此上下文相关联，以在它们之间创建一些逻辑关联，从而允许设备性能优化。例如，大型顺序写入模式可能通过允许设备改善内部局部性 (locality) 并减少一些开销（例如，如果在写入过程中允许某个大数据单元作为一个整体受到电源故障的影响，那么填充此单元的所有命令可以更快地工作，因为它们可以减少通常需要为每次写入单独提供电源故障保护的开销）来获得更好的性能。此外，处理多个并发上下文允许设备在它们全部混合在一起时更好地识别每个写入模式。

设备可以支持的最大上下文数量在几何描述符 (Geometry Descriptor) 的 bMaxContextNumber 字段中报告。当主机配置设备时，它将此数量分配到创建的 LU 中，并将每个 LU 要支持的上下文数量写入配置描述符 (Configuration Descriptor) 的 wContextCapabilities 字段。

要使用上下文，应选择一个可用的上下文 ID (Context ID)。然后，应通过写入相关 LU 的配置属性 (wContextConf) 来初始化它。然后，可以通过在读/写命令的 CDB 的组号 (GROUP NUMBER) 字段中指定上下文 ID 来读取/写入与该上下文关联的数据。当不再使用上下文时，主机应将配置属性 (wContextConf) 写入全 ‘00’ 以关闭上下文。在重新配置另一个配置/用途之前，应先关闭上下文。

电源循环后不应有任何 ContextID 处于打开状态。

10.1 上下文配置

在使用任何上下文之前，应先对其进行配置。

配置通过设置相关 LU 的上下文配置属性（将 wContextConf 设置为 INDEX 等于 LUN，SELECTOR 等于 ContextID，SELECTOR ‘0’ 保留）来完成。然后，所有与此 ContextID 关联的读命令或写命令都应使用组号 (GROUP NUMBER) 设置为 ContextID 来发送。

当不再需要上下文时，应通过向配置属性写入零字节来关闭它。

要为特定 LU 配置特定 ContextID，应将以下字段写入所需特定上下文的上下文配置属性：

• 激活和方向模式（只读、只写或读/写）

  方向指示此上下文的所有后续访问是只读、只写还是读/写。向此字段写入非零方向是上下文的“激活代码”。此字段中的零表示关闭的上下文，在重新配置之前不能再由其 ID 寻址。读/写上下文与只读或只写上下文相比，性能可能降低

• 大单元上下文标志 (Large Unit context flag)

  这指示上下文是否遵循大单元 (Large Unit) 规则。大单元 (Large Unit) 是可用于大型顺序读/写操作的最小单元，以减少内部开销并提高性能。

  • 如果设置了大单元上下文标志，则使用大单元乘数 (Large Unit multiplier) 来指定更大的单元大小。

• 可靠性模式 (Reliability mode)

  控制写入上下文的数据应如何响应中断。

11 系统数据标签机制 (System Data Tag Mechanism)

系统数据标签机制使主机能够在发送系统数据进行存储（例如文件系统元数据、操作系统数据、时间戳、配置参数等）时通知设备。此通知（使用 CDB 中的组号 (GROUP NUMBER) 字段）将指导设备以最佳方式处理系统数据。通过将存储特性与系统数据特性相匹配，设备可以提高读取和更新操作的访问速率，并提供更可靠和稳健的存储特性。

UFS 设备具有有限数量的系统数据区域 (System Data area)，这是一个具有特殊特性的存储区域，这些特性针对系统数据的特性和需求量身定制。当收到带有系统数据标签通知的写入命令时，设备会将系统数据存储在系统数据区域中。如果可用于存储系统数据的容量完全耗尽，设备会将系统数据存储在常规存储中，并且 wExceptionEventStatus 属性中的 SYSPOOL_EXHAUSTED 位应设置为 1。此外，如果 SYSPOOL_EVENT_EN 位等于 1，则 RESPONSE UPIU 中存在的设备信息字段中的 EVENT_ALERT 位将被强制设置为 1。

SYSPOOL_EVENT_EN 位包含在 wExceptionEventControl 属性中。

主机可以通过解除映射 (unmapping) 先前使用系统数据标签特性写入的 LBA 来释放系统数据区域。

设备以系统数据单元 (system data unit) 为单位处理系统数据标签机制，系统数据单元的大小是设备特定的，可以通过读取几何描述符 (Geometry Descriptor) 中的 bSysDataTagUnitSize 参数来检索。

系统数据的总可用容量由几何描述符 (Geometry descriptor) 的 bSysDataTagResSize 参数指示。

当主机在写入操作期间标记系统数据时，整个 bSysDataTagUnitSize 大小的存储区域将被设备视为系统数据区域，即使正在写入的数据大小小于 bSysDataTagUnitSize。此外，任何更新系统数据单元但数据未标记为系统数据的命令（写入、取消映射等）都会将整个系统数据单元的存储特性更改为常规数据。因此，建议以完整的 bSysDataTagUnitSize 大小的单元处理系统数据。

系统数据区域仅在普通内存类型 (Normal memory type) 的逻辑单元中可用。

12 异常事件机制 (Exception Events Mechanism)

异常事件机制由设备用来向主机报告某些事件的发生。

它由三个部分组成：EVENT_ALERT 位、wExceptionEventStatus 属性和 wExceptionEventControl 属性：

• wExceptionEventStatus 属性中的一个位分配给每个异常事件。当相应的异常事件处于活动状态时，设备应将 wExceptionEventStatus 位设置为 1，否则应设置为 0。

• wExceptionEventControl 属性中的一个位分配给每个异常事件。

  如果至少有一个 wExceptionEventStatus 位和对应的 wExceptionEventControl 位对被设置为 1，则 EVENT_ALERT 位应被设置。

  将 wExceptionEventStatus 位设置为 1 如果对应的 wExceptionEventControl 位为 0，则不会强制 EVENT_ALERT 位为 1。

• EVENT_ALERT 是 RESPONSE UPIU 的设备信息 (Device Information) 字段中的一个位，它是所有 wExceptionEventStatus 位经过 wExceptionEventControl 位掩码后的逻辑或 (logical OR)。当 wExceptionEventStatus 中至少有一个位被设置且对应的 wExceptionEventControl 位为 1 时，EVENT_ALERT 位被设置为 1。如果 wExceptionEventControl 中启用的所有异常事件都不活动，则 EVENT_ALERT 设置为 0。

定义了七个异常事件：动态设备容量、系统池耗尽、后台操作、温度过高、温度过低、性能限制和 WriteBooster 缓冲区刷新。与这些异常事件关联的 wExceptionEventStatus 中的位描述如下：

• DYNCAP_NEEDED – 设备请求动态容量操作（参见 动态设备容量）。一旦动态容量操作成功完成，释放了设备请求释放的全部容量，此位即被清除。
• SYSPOOL_EXHAUSTED – 设备耗尽了将更多主机数据视为系统数据的资源（参见 系统数据标签机制）。一旦主机已将足够多的先前作为系统数据区域处理的内存区域转换为非系统数据区域，此位即被清除。
• URGENT_BKOPS – 设备请求主机注意后台操作的需求级别（参见 后台操作模式）。一旦 bBackgroundOpStatus 返回到 00h 或 01h，此位即被清除。
• TOO_HIGH_TEMP – 设备请求主机采取措施降低设备外壳温度 (Tease temperature)。
• TOO_LOW_TEMP – 设备请求主机采取措施提高设备的外壳温度 (Tease temperature)。
• PERFORMANCE_THROTTLING – 设备正在以降低的性能运行。主机应通过异常事件机制收到通知。
• WRITEBOOSTER_FLUSH_NEEDED – WriteBooster 的缓冲区需要刷新。主机应通过将 fWriteBoosterBufferFlushEn 设置为 ‘1’ 来发出刷新命令。

在 RESPONSE UPIU 的设备信息字段中，设备仅指示通过写入 wExceptionEventControl 属性由主机启用的事件。当满足清除条件时，设备会清除 wExceptionEventStatus 属性中和 Response UPIU 的设备信息字段中的事件位。

13 队列深度定义 (Queue Depth Definition)

每个逻辑单元负责管理自己的任务集 (task set)。独立于任务集，用于排队任务的资源可以静态分配给每个 LU（因此 LU 能够排队新任务达到一定深度），或者由所有 LU 共享（因此排队资源根据收到的任务动态分配给 LU）。

设备可以实现上述两种排队架构之一。设备通过设备描述符和单元描述符中的只读参数通知主机软件所实施的策略。

队列的深度 (depth) 定义为可以存储在队列中的待处理命令 (pending commands) 的数量。

13.1 共享队列 (Shared Queue)

在共享队列架构中，设备具有固定深度的队列，任务在收到时排队，无论其 LUN 指定如何。

当收到 COMMAND UPIU 时，从共享队列分配资源，并且该命令计入队列深度限制。主机应跟踪队列深度，并且发出的命令不应超过队列可存储的数量。如果队列资源不可用，设备应返回带有 TASK SET FULL 状态的响应。

QUERY REQUEST UPIU、NOP OUT UPIU 和 TASK MANAGEMENT REQUEST UPIU 不存储在共享队列中。

13.2 每逻辑单元队列 (Per-Logical Unit Queues)

在每 LU 排队架构中，设备实现独立的固定深度队列，每个 LU 一个队列，换句话说，为每个 LU 分配固定数量的排队资源。

当收到 COMMAND UPIU 时，从其逻辑单元（由 UPIU 头中的 LUN 字段指示）关联的队列分配资源。该命令计入相应队列的深度限制。主机应跟踪队列深度，并且发出的命令不应超过其指定队列可存储的数量。如果指定 LU 的资源不可用，设备应返回带有 TASK SET FULL 状态的响应（即使其他 LU 有可用的排队资源）。

QUERY REQUEST UPIU、NOP OUT UPIU 和 TASK MANAGEMENT REQUEST UPIU 不存储在 LU 队列中。

当实现此排队架构时，单元描述符中的 bLUQueueDepth 参数应指示每个逻辑单元的队列深度。如果逻辑单元已启用，其单元描述符中的 bLUQueueDepth 值应等于或大于 1。

设备描述符中的 bQueueDepth 参数应等于 0。

注：为了与标准的先前修订版向后兼容，如果 LU 的 bLUQueueDepth 为 0，且 bQueueDepth 也为 0，则队列深度应由主机视为未知。主机应使用软件算法推断队列深度。

13.3 RPMB 众所周知逻辑单元队列

RPMB 逻辑单元可以使用共享队列资源，也可以使用其自己独立的队列，具体由设备制造商实现。

如果 RPMB 逻辑单元使用共享队列资源，其 bLUQueueDepth 参数应等于 0。当收到 COMMAND UPIU 时，从共享队列分配资源，并且该命令计入队列深度限制。主机应跟踪队列深度，并且发出的命令不应超过队列可存储的数量。如果队列资源不可用，设备应返回带有 TASK SET FULL 状态的响应。

如果 RPMB 逻辑单元使用独立队列，其 bLUQueueDepth 参数应等于 1。主机在任何给定时间不应向 RPMB LU 发出超过一个命令。如果向 RPMB LU 发出多个命令，设备应返回带有 TASK SET FULL 状态的响应。

应注意，与其他 LU 不同，允许 RPMB LU 具有固定深度队列，而其他 LU 使用共享队列。

14 设备寿命模式 (Device Life Span Mode)

此模式的目的是通过增加设备耐久性 (endurance) 来延长设备寿命。设备使用磨损均衡 (wear leveling) 等机制来延长由内存供应商给出的 P/E 循环次数 (P/E cycle count) 限制的设备寿命时间。在此模式下，设备可以在操作时使用较低编程电压 (lower programming voltage) 等技术来增加 P/E 循环次数，从而延长设备寿命。

UFS 中的读写操作性能非常高。然而，并非总是需要最大操作速度，例如当用户睡眠、设备处于熄屏模式、下载大文件/视频等时。在此类场景下，UFS 主机可以通过启用 fDeviceLifeSpanModeEn 标志来指示设备在操作时使用较低编程电压等技术。禁用此标志后，设备使用正常电压进行操作。预计设备在标志禁用后将立即正常响应。

在此模式下可能存在性能下降，因此 fDeviceLifeSpanModeEn 应仅在设备未主动使用时设置。

设备寿命的改善取决于设备实现。

设备寿命模式启用

fDeviceLifeSpanModeEn 是用于启用或禁用操作时使用较低编程电压等技术的标志。

• 0 = 设备寿命模式禁用。

• 1 = 设备寿命模式启用。

  此标志的默认值为零。主机可以根据熄屏、下载大文件等场景启用此标志。

15 刷新操作 (Refresh Operation)

为了提高可靠性（例如，保持力 (retention)），可以通过擦除和重新编程其物理块在物理块级别刷新设备数据。

刷新操作机制为显式控制刷新操作提供了更好的能力，包括刷新配置、启动、中断和进度管理。

此功能是可选的。设备通过设备描述符中的 bUFSFeaturesSupport 参数指示是否支持该功能。它旨在满足可靠性要求。

此功能对可靠性的改善程度取决于设备实现。

15.1 配置

15.1.1 刷新方法 (Refresh Method)

从刷新的角度来看，存在三种类型的块：

• 类型 1：不包含数据的物理块（即未映射的物理块）。此类块不会被刷新。
• 类型 2：包含数据但设备不认为它们需要刷新的物理块。
• 类型 3：包含数据且设备认为它们需要刷新的物理块。

设备应支持两种刷新方法：手动强制 (Manual-Force) 或手动选择性 (Manual-Selective)。

• 手动强制 (Manual-Force)

  设备有义务刷新主机请求数量的物理块，无论这些块是否需要刷新。仅类型 2 和类型 3 块会被刷新。

• 手动选择性 (Manual-Selective)

  设备仅刷新其认为需要刷新的物理块。具体来说就是类型 3 的块。

在启动设备刷新操作之前，属性 bRefreshMethod 需要初始设置为手动强制或手动选择性模式。

根据主机请求，设备应按照指定的方法（手动强制或手动选择性）执行刷新操作。除了主机启动的刷新模式外，设备还可以实现主机透明的额外自动刷新模式。

15.1.2 刷新单元 (Refresh Unit)

主机可以配置 bRefreshUnit 属性以指定单次刷新请求要刷新的物理块数量。

设备刷新由 bRefreshUnit 指定数量的物理块，从第一个物理块开始。为了刷新整个设备（即所有物理块），主机必须发送一次（bRefreshUnit = 01h: 100%）或多次（bRefreshUnit = 00h: 设备的最小刷新能力）刷新命令。

在任何情况下，当 dRefreshProgress 达到 100000 (100.000%) 时，设备停止刷新。

15.1.3 刷新频率 (Refresh Frequency)

设备以月为单位提供刷新频率指示器 (bRefreshFreq 属性)。主机应确保整个设备在 bRefreshFreq 属性指定的时间段内被刷新。dRefreshTotalCount 递增以指示整个设备刷新完成。

由于所需的刷新频率取决于使用条件（例如，温度），bRefreshFreq 属性可由 OEM 配置，以便主机了解需要发送刷新请求的频率。

15.2 启动和中断

主机通过将 fRefreshEnable 设置为 1b 来启动刷新操作，并通过将 fRefreshEnable 清除为 0b 来中断它。中断后，也可以通过将 fRefreshEnable 设置为 1b 来恢复刷新操作，从上次停止的地方继续。

bRefreshStatus 属性提供有关单次刷新操作状态的信息。

15.3 进度管理 (Progress Management)

设备应指示相对于其整个物理块的刷新进度。设备健康描述符 (Device Health Descriptor) 中定义了两个参数作为进度监视器：

• dRefreshTotalCount

  指示设备完成整个设备刷新的次数。当 dRefreshProgress 达到 100% 时增加 1。

• dRefreshProgress

  以百分比指示相对于其整个物理块的刷新进度。

它们在手动强制和手动选择性方法中都有效，并且不会被刷新操作以外的任何操作（例如 WRITE(10)）更改。

主机有责任基于以下因素保持发送刷新请求的节奏：

• 刷新频率 (Refresh Frequency) (bRefreshFreq)
• 刷新单元 (Refresh Unit) (bRefreshUnit)
• 进度监视器 (Progress monitor) (dRefreshProgress, dRefreshTotalCount)

16 温度事件通知 (Temperature Event Notification)

此功能的目的是在 UFS 设备温度接近定义的上下限边界时提前向主机提供通知。此功能是可选的。bUFSFeaturesSupport 参数中的两个位指定了温度事件通知支持（参见 14.1.4.2 “设备描述符”）。

当设备温度过高或过低需要主机注意时，设备应使用 13.4.12 中定义的异常事件机制中的 wExceptionEventStatus 属性通知主机此情况。当 wExceptionEventStatus 中引发 TOO_HIGH_TEMP 时，建议主机进行限制 (throttling) 或其他冷却活动以降低设备外壳温度 (Tease temperature)。当 wExceptionEventStatus 中引发 TOO_LOW_TEMP 时，建议主机采取措施提高设备的外壳温度。

当此温度警报引发时，主机可能想知道设备报告的温度，即使 UFS 设备只能给出粗略温度。为此目的，应通过 bDeviceCaseRoughTemperature 属性提供设备外壳粗略温度。由于半导体设备内部的温度传感器预计不够精确，bDeviceCaseRoughTemperature 中显示的温度信息仅用于提供粗略的温度范围。并且根据测量位置的不同可能会有一些变化，主机应假设来自设备的此温度信息具有大约 ±10 °C 的误差范围。因此，主机应仅将此温度信息作为设备外壳的粗略温度参考。

为了提供过高或过低温度警报的温度边界信息，定义了 bDeviceTooHighTempBoundary 和 bDeviceTooLowTempBoundary 属性。当设备外壳温度回到边界温度范围内时，wExceptionEventStatus 中的温度警报状态字段应由设备自动清除。

17 性能限制事件通知 (Performance Throttling Event Notification)

此功能的目的是在设备限制性能时通知主机。如果设备需要降低性能，将通过 13.4.11 中定义的异常事件机制通知主机。当 PERFORMANCE_THROTTLING 异常事件位置位时，主机应预期设备的性能降低。

主机可以读取设备的 bThrottlingStatus 属性以发现设备在较低性能下运行的原因。bThrottlingStatus 属性中的位将在条件存在期间保持设置。

此功能是可选的。设备通过设备描述符中的 dExtendedUFSFeaturesSupport 参数指示是否支持该功能。

当通知性能限制事件时，UFS 设备的性能降低了多少取决于设备实现。