nvme 盘写放大

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盘写统计数据

[[email protected] 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
[[email protected] 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的物理空间写的总量，后者可以认为是来自用户的写请求总量，可以认为一段时间内两者增量之比值就是该时间段内的写放大系数。

原文地址：http://blog.51cto.com/xiamachao/2298006

时间： 2024-08-29 06:22:35