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).
闯关第三步：NVME驱动层
这部分对IO没有merge，主要是获取nvme盘硬件的原子写能力，然后通过块设备层接口对块设备相关的原子写能力进行设置。
