1. SSD 盘内部写操作的来源
1.1 用户请求
和其他存储介质一样，用户的写请求的数据及其相关meta 数据更新，是驱动SSD写操作的主要来源。
1.2 垃圾回收（GC）
基于SSD介质需要擦除之后才能写同一个位置的特性，对SSD逻辑地址的覆盖写会变成内部SSD物理地址的追加写，而对之前占用的物理地址空间就需要回收。这些空间通常是尽量凑成整个Block去回收，为此Block 内部的有效数据就需要搬迁，这就导致了额外的写。
1.3 磨损均衡 （wear leveling)
类似的限制是磨损均衡，为了保证不同块的PE尽量均衡，内部有时也可能需要搬迁数据。
1.4 坏块管理
坏块上的数据需要搬迁，这也会导致内部额外的写操作。
1.5 读干扰 （Read Disturb)
当某个闪存块的读的次数达到一定阈值的时候，FTL会把这些数据从该闪存块搬走以避免数据出错。
1.6 数据保持 （Data Retention)
由于电荷流失，闪存块上的数据保持可能出现问题，为此FTL需要搬迁这些数据。
2. nvme盘写放大统计
从上面的介绍可以看到SSD内部有许多种额外的写操作，为了分析这些写操作对用户写请求的影响，就需要统计出这些数据。
对于nvme 盘，可以借助nvme cli工具去获取相关数据。
2.1 准备工作
在linux系统上，可以下载并编译nvme cli工具：
git clone https://github.com/linux-nvme/nvme-cli.git
cd nvme-cli
make
如果出现下面的问题：
NVME_VERSION = 1.6.72.g43f2.dirty
cc -D_GNU_SOURCE -D__CHECK_ENDIAN__ -O2 -g -Wall -Werror -std=gnu99 -DNVME_VERSION='"1.6.72.g43f2.dirty"' -c nvme-print.c
In file included from nvme.h:34:0,
from nvme-print.h:4,
from nvme-print.c:6:
linux/nvme.h:19:24: fatal error: linux/uuid.h: No such file or directory
可以参考下面的方法解决：
修改如下：
#ifndef _LINUX_NVME_H
#define _LINUX_NVME_H
#include <linux/types.h>
//#include <linux/uuid.h> // 注释掉这行
2.2 确定nvme盘类型
使用lsscsi /smart 获取相关盘的类型
2.3 读取nvme盘写统计数据
[root@localhost nvme-cli]# ./nvme intel smart-log-add /dev/nvme0n1
Additional Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
key normalized raw
program_fail_count : 100% 0
erase_fail_count : 100% 0
wear_leveling : 96% min: 164, max: 206, avg: 190
end_to_end_error_detection_count: 100% 0
crc_error_count : 100% 0
timed_workload_media_wear : 100% 63.999%
timed_workload_host_reads : 100% 65535%
timed_workload_timer : 100% 65535 min
thermal_throttle_status : 100% 0%, cnt: 0
retry_buffer_overflow_count : 100% 0
pll_lock_loss_count : 100% 0
nand_bytes_written : 100% sectors: 7654336
host_bytes_written : 100% sectors: 6398681
[root@localhost nvme-cli]# ./nvme intel smart-log-add /dev/nvme0n1
Additional Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
key normalized raw
program_fail_count : 100% 0
erase_fail_count : 100% 0
wear_leveling : 96% min: 164, max: 206, avg: 190
end_to_end_error_detection_count: 100% 0
crc_error_count : 100% 0
timed_workload_media_wear : 100% 63.999%
timed_workload_host_reads : 100% 65535%
timed_workload_timer : 100% 65535 min
thermal_throttle_status : 100% 0%, cnt: 0
retry_buffer_overflow_count : 100% 0
pll_lock_loss_count : 100% 0
nand_bytes_written : 100% sectors: 7654576
host_bytes_written : 100% sectors: 6398903
对比上面的两组数据可以看到，nand_bytes_written/host_bytes_written都在增加，前者是内部SSD的物理空间写的总量，后者可以认为是来自用户的写请求总量，可以认为一段时间内两者增量之比值就是该时间段内的写放大系数。