神楽坂雪紀的投研笔记

这篇 IO 通路简析主要偏向于模块之间的衔接，不涉及模块内的细节，主要回答下面的 4 个问题： 1. 在何处向请求队列注册 make request function 函数（这里是 pblk_make_rq） 2. 在何处调用了（1）注册的 make request function 函数 3. 在何处向请求队列注册了 request function 函数（这里是 pci.c 中的 nvme_queue_rq） 4. 在何处调用了（3）注册的 request function 函数

基于 UFS 的 Open Channel FTL 实现与基于 NVMe 的实现思路类似，可按层划分为三个大步骤，自下而上分别为：

1. UFS 设备侧的 FTL 相关功能修改；
2. 主机侧 UFS 驱动程序的操作命令扩展；
3. 主机侧软件定义的 FTL 功能实现。

基本结构图

下图是 pblk 的结构图，其中给出了 read 请求和 write 请求的操作示意图，以及 pblk 核心的几个数据结构——L2P table、write buffer、write context。关于具体操作的细节我们在后面的小节给出：

LightNVM[1] 是 CNEXLabs 针对 Open Channel SSD（以下简称 OCSSD）在 Linux 内核中的一种实现，分支托管在 GitHub 上，目前能找到最早的提交记录是 2015-10-29。LightNVM 的程序栈由三层组成，每一层都向用户空间提供了 OCSSD 的抽象（即用户可以直接与这三层进行 IO 交互而不用经过文件系统，后面会细提到）。示意图如下图所示：

SSD 的特点

SSD 设备的存储单元主要是 NAND Flash[1]，按 page 写入，按 block 擦除，一个 block 内有多个 page，并且擦除的次数有限。根据以上的特点，在使用设备时，必然存在这样的情况：在一个 block 中，有部分 page 保存了有效数据，剩下的 page 全被标记为无效，如果要擦除这个 block，就必须首先将其中的有效数据转移到其他 block，然后才能擦除当前 block，这个过程被称为 GC。

要使用 Open-Channel SSD，需要得到操作系统内核支持。 随着 LightNVM 的加入，4.4 版本后的 linux 内核都可以支持。该项目仍然处于开发中，最新的源代码可从 https://github.com/OpenChannelSSD/linux 获得。启用了相应的内核支持后，必须满足以下条件：

Open-Channel SSD 是一种设备，与 SSD 不同之处在于，前者将 SSD 的 FTL(Flash Translation Layer) 提出来，交给主机管理与维护，其优点是：高吞吐，低延迟，高并行。LightNVM 则是 Open-Channel SSD 在主机上的驱动程序扩展。

按照惯例，Hello World !

记录一下博客的迁移记录。本站点目前架设在 bandwagonhost 上，运行 CentOS-Minimal，我将其命名为 Spiral（略显中二），一年开销 ＄11.99。最开始只跑着个 Shadowsocks，512M 的内存实际使用中的不足 20M，长期处于空转中。直到本月初阿里云上的学生机也到期了，于是决定尝试下 Typecho。