1.NVMe原子写简介

NVME协议家族，当前发展的已经非常庞大，来张nvme家族大合影。从最开始的NVME Base Spec，又延伸了更加专业聚焦的模块Command Set Spec、Transport Spec，NVME MI Spec等等。

在Command Set Spec中，我们可以看到针对nvme设备相关的原子操作的定义相关参数。原子写的简单理解就是，一笔写操作，要不全部写入盘，要不全部未写入盘，不存在部分写入+部分未写入的情况，最大限度保证数据一致性。

从nvme协议中的定义来看，原子写参数主要分为三大类：控制器controller级别、namespace级别以及namespace原子写边界相关参数。

AWUN：Atomic Write Unit Normal，这个参数是定义了控制器级别的原子写参数，以block数量为单位，常见的盘的block的大小有512B、4K、16K等。单个block本身就有原子写属性。当写入IO=<AWUN，该IO可以完成原子写的操作。不过需要注意，当写入IO>=AWUN时，且namespace没有设定原子写操作参数，会失去原子写的能力，NVME盘是不会有相关错误返回，需要上层用户自己掌控原子写的约束条件。

下图示例，AWUN=2KB，每个LBA 512B。假设两笔原子写操作：A原子写命令填充LBA0-3数据，B原子写命令填充LBA1-4数据，且均小于等于AWUN的原子写单位。那么，有效的结果就是前2行，要么LBA0-3 A+ LBA4 B，要么LBA0 A+LBA1-4 B，每一笔写入都是原子操作，不能出现后两种部分写入的情况。

AWUPF：Atomic Write Unit Power Fail，这个比较好理解，当出现异常掉电的情况，当写入IO=<AWUPF时，可以保证原子写的能力，同时也要求AWUPF=<AWUN, 不能超过控制器本身的原子写的能力。企业级SSD中通常有PLP掉电保护的大电容，不会影响数据安全，消费级SSD如果使用原子写能力，可能需要重点关注这项。在linux系统中，可以通过nvme_id_ctrl相关的命令获取原子写参数的配置

struct nvme_id_ctrl {
   ...
   __u8 tnvmcap[16];
   __u8 unvmcap[16];
   ...
   __le16 awun;
   __le16 awupf;
   __le16 acwu;
   ...
};

NAWUN/NAWPF：这两个参数是Namespace级别的，定义与AWUN/AWUPF类似，控制器级别的参数也可以用于namespace级别原子写，需要注意的是，namespace级别原子写的参数>=控制器级别的原子写参数，比如NAWUN>=AWUN, NAWUPF>=AWUPF. 也就是说，namespace级别原子写支持更大的原子写能力。此外，Namespace级别原子写需要注意LBA边界的问题
ACWU/NACWU：这两个参数是控制器和namespace相关的比较&写两种操作原子能力参数。不过，这个在nvme协议里面也是optional的，没有特别具体的定义，nvme盘基本不支持这个特性。
NABSN/NABO/NABSPF：这三个参数定义的是Namespace级别的原子写操作边界，在nvme协议规范中也是Optional的。

如下图示例，黄色或者蓝色的4个格子是一个边界大小NABSN/NABSPF，原子写操作要符合规则的定义，不能夸边界原子写操作。NABSN/NABSPF要大于等于NAWUN/NAWPF，且NABO小于等于NABSN/NABSPF，用一个对比关系式：NABSN/NABSPF>=(NAWUN/NAWPF & NABO).

但也需要注意，如果控制器AWUN/AWUPF/ACWU限制为0，即使出现跨边界的写，在控制器级别也是可以完成原子写操作，可以不用管NABSN/NABSPF这些namespace的边界约束。

2.应用场景

在数据库应用场景中，对数据一致性有很高的要求。比如在MySQL InnoDB场景，page size是16KB，数据校验也是16KB。但是盘通常是block size是4KB，导致在某些场景（比如掉电场景）无法保证16KB原子写落盘，出现partial write问题。为了解决这个问题，MySQL会在脏数据下刷到文件时，会先复制到double write buffer。然后double write buffer分2次在写入共享表空间，最后通过fsync刷新到硬盘。

double write buffer带来的负面影响就是会有额外的开销，在MySQL官网也是推荐采用O_Direct的方式降低double write buffer的影响。在DirectIO模式下，可以把数据以DMA的形式写入SSD中，避免了buffering IO相关的脏数据问题，降低延迟抖动的影响。

支持Direct IO写入的数据库类型主要有：

Oracle
SAP HANA
MySQL (InnoDB storage engine)
RocksDB
PostgreSQL
Teradata

基于MySQL数据库Direct IO模式应用场景，如果要使用硬件的原子写能力，要经过文件系统、block层、驱动层，才能闯关成功。

闯关第一步：文件系统

此时，文件系统Direct IO模式可以绕过文件系统的缓存，直接写入，文件系统不会有太多的影响，会通过BIO提交IO到Block层。比如ext4文件系统中，通过ext4_direct_IO下发到块设备中。

闯关第二步：Block块设备层

在block块设备层，可能会出现IO merge合并和IO Split拆分的情况。如果要原子写的效果，在Block层就不能发生IO拆分或者合并的情况。

在linux内核中，可以查询merge是否已开启：

cat /sys/class/block/device-name/queue/nomerges

This enables the user to disable the lookup logic involved with IO merging requests in the block layer. By default (0) all merges are enabled. When set to 1 only simple one-hit merges will be tried. When set to 2 no merge algorithms will be tried (including one-hit or more complex tree/hash lookups).