JESD219 Workload学习

1:什么是JESD219

JESD219协议全称SSD Endurance Workload，是用于描述SSD的标准测试规范，规定了一套端到端的测试方法评估SSD耐久性和性能，统一了各个厂家的测试标准，帮助确保SSD的质量、可靠性和性能。

JESD219分为： Endurance Workload and Client Workload

2:为什么要有JESD219

SSD使用NAND进行存储，NAND的寿命一般使用PE cycle次数（program/Erase)来表示。

Nand以Page写入，以Block擦除，通过GC的机制来回收被无效数据占用的空闲空间，此过程就会产生P/E。

GC又会带来写放大，不同的Workload有不同的写放大因子，WAF写放大因子越大，导致PE消耗增加越多。所以在不同workload测试的寿命数据不同

常见的Workload:顺序，纯4K随机，JESD219 workload，顺序读写WAF最理想， JESD219最符合实际应用场景

PE cycle -->GC -->WAF-->Workload impact

所以固态硬盘的工作负载对其能够写入的数据量(也就是寿命)有着巨大的影响，JESD议里规定了消费级和企业级Endurance Workload，提供了通用化，标准化的工作负载，使用JESD219提供的workload测试不同厂商的SSD，得出的结果更具有可比性。

3.Enterprise Workload特性和要求

进行219 Enterprise Workload 测试，先应填盘有效数据，避免SSD在执行workload TEST期间，由于LBA的内容而导致驱动返回 data read error。如果Formatted SSD已经满足了测试要求，就可以直接进行Workload测试。

a) Payload size 分布比例:

b) 各种Payload按照一定要求排布原则

>=4096 的数据按照一定顺序排列，于4k的要保证4k边界对齐。可能会提升FW效率。

C）数据访问量分布：分为三组，80%的冷数据占有20%的访问量。

1) 50% of accesses to first 5% of user LBA space (LBA group a)

2) 30% of accesses to next 15% of user LBA space (LBA group b)

3) 20% of accesses to remainder of user LBA space (LBA group c)

具体的Workload 读写操作，通过IO引擎参数配置，W/R比例，时间, Pattern 等等。

访问量实现，有两种方法

1：Deterministic Method

按照一定顺序重复执行对应group的IO工作

2：Random Method：在三个group中随机交叉访问进行。

基于a/b/c的workload要求产生 相应的权重因子，权重因子大的，表示访问它的概率就大，根据这些权重因子，去随机产生IO，所以宏观上是随机交叉执行的

d) 避免测试单一区域

为了避免只测试SSD的特定区域，c)描述的分布通过在不同的测试单元上偏移用户LBA空间，以使所有SSD的LBA都受到最高数量的访问

e)写入数据负载原则：

1.写入数据有效负载大小分布应同时应用于这三个LBA组

2.访问百分比符合4C中的比例。

3.每个LBA group中的访问是随机的

f) 随机数据原则

随机数据被认为具有100%的熵，即完全混乱无序化。生成随机数据的方法，不做限制。

对于随机化数据，如果测试中SSD执行数据压缩操作，那么这种操作对数据的影响和加密操作相同。

在数据随机原则下，也可以在每个sector中的随机数据一些byte替换为Metadata，例如LBA号和其他一些有用信息，前提是这些信息可以增强测试解释能力。Phxio 支持每个LBA有Header/Meta,类似这种操作，保证同一个LBA重复写的数据也不同

4.Client Workload Overview

Client Endurance Workload application：1.Preconditioning Phase 2.Test Phase

1）Preconditioning Phase steps:

1.使用随机数据一次性按顺序写入完整的LBA地址空间 100%（当前使用）

2.如果PreCond%full值小于100％，则从最大的LBA连续创建自由的LBA空间，该LBA位于与PreCond%full值相对应的较低LBA地址。

2)Test Phase

Test Phase会多次运行Test Trace。这些Test Trace的目标是模拟客户端环境中的实际使用情况。每次迭代使用相同的LBA足记，以确保测试的一致性和可比性.

5.Client Traces

1.Reference Trace

一种command trace，是SSD Test Trace库SSD容量范围中的一种，包含对代表性SSD的所有IO操作，包含开机/启动，休眠/激活期间内发生的一系列操作，理解为命令流。主要有：write command， trim command， flush command。

Client Worklaod不能应用于作为缓存应用的SSD测试。

2.Test Trace

拥有Reference Trace的所有命令集。Test Trace涵盖了驱动器所有LBA Range 范围。并将连续Trim命令合并为单个Trim 命令，减少冗余。

JEDEC Trace Lib中存在多个Test Trace，每个Test Trace对应于特定的SSD容量参数值。这意味着针对不同的SSD容量，可以使用相应的Test Trace来进行评估，从而更准确地反映出不同容量下的SSD性能和行为特征

具体Test Trace 可以通过扩展或者压缩Reference Trace来满足不同容量SSD的test 需求。

Compression 压缩：通过减少Trace中 cold lba ranges的长度实现。

Expansion 扩展：通过增加Trace中的Cold LBA Range长度实现。

Reference Trace构成：Trace = Hot + Cold

（什么是Cold LBA： An LBA Range not referenced by a write or trim in a trace.）

扩展压缩方式：

在压缩和扩展过程中，cold LBA长度将根据原始长度比例进行调整。Hot数据不做改动。

假设Reference Trace中Cold LBA长度为C，那么每一段大于20MB的individual Cold LBA Range，都将压缩或者扩展(M-T)/C * Individual Length的Cold LBA，形成新的Test Trace。

调整的步长应该是4KB的倍数。这样做是为了确保调整后的冷LBA范围长度保持4KB的对齐，从而避免数据的碎片化和对性能的影响