神楽坂雪紀的投研笔记

故事是这样的，原导师离职，所以更换了导师，加入了一个搞分布式文件系统的课题组。暂时给的课题是先学习 ceph 和 ipfs，并把环境搭建起来分析源码。导师留下了几台电脑没人用，所有就拿过来重整了一下。

本学期校园网打击个人 WiFi 的行为可谓到了极端的地步，根据脚本日志显示，路由器通过 drcom.py 连接的方式平均每天要掉 8 次以上，而且还会每隔十几分钟就中断连接数十秒，真是非常难受了。于是暂时的解决方案是这样的：

核心数据结构分析

fios 队列结构：

1
2
3
4
5
6

struct fios_queue {
    pid_t pid;                  // 进程的pid
    struct rb_node fiosq_node;  // 将fios queue插入到fios rb-tree，主要用于在dispatch阶段，快速的取出下一个要被处理的fios queue
    struct rb_node pid_node;    // 将fios queue插入到pid rb-tree，主要用于在插入请求add request阶段，能够快速的通过进程pid找到要插入的fios queue
    struct rb_root rq_list;     // 组织请求
    struct list_head fifo;      // 为了确保不会出现请求饥饿

内核版本：Linux-4.19

Lightnvm 与 pblk

Lightnvm 与 pblk 的关系，类似于 linux 块层与 IO 调度器之间的关系。即在 lightnvm 中可以有多种 FTL 的实现，这里 pblk 就是一种 FTL 的实现。Lightnvm 子系统在支持PPA接口的块设备的基础上进行初始化。该模块使内核能够通过内部 nvm_dev 数据结构和 sysfs 等来暴露设备的几何结构信息。通过这种方式，FTL 和用户空间的应用程序可以在使用前就了解到设备的底层信息。此外 Lightnvm 子系统还有一个最重要的功能——管理 target 的划分以及指定用于管理 target 的 FTL。

时间片管理

CFQ的时间片管理

CFQ 的时间片管理如下图。每个请求队列 cfq queue 的时间片用完后，都要通过【选择 cfq group -> 选择 service tree -> 选择 cfq queue】的流程，从其自身维护的数据结构中找出下一个要被调度的请求队列，整个选择相当于根据一个优先级顺序不断地遍历这个数据结构。当一个 cfq queue 的时间片用尽，就要等到下一轮遍历回来才能被调度。

block layer 的最核心功能可分为两部分——接受上层提交的请求；对请求进行调度。其中 block layer 的入口函数为：submit_bio。如下图所示：

23岁了。直面生活压力，开始关注起宏观层面的经济发展问题。坊间传言，这颗星球上有两大巨型的泡沫，分别是美国的股市和中国的房地产市场，这两者的任一个被刺破，都将引起翻天覆地的巨大冲击，甚至能彻底冲垮某些小国家的经济。经济学家Robert Shiller教授在《非理性繁荣》一书中，以20世纪初的美国科技股泡沫为切入点，分析了导致市场泡沫的结构因素、文化因素、心理因素等多个层面，呼吁大众理性投资。尽管大众都知道应该理性投资，然而只要市场还存在，投机性泡沫就无法被消除，除非构建一个全新的经济秩序以维持长久持续的理性繁荣（《新金融秩序——如何应对不确定的金融风险》）。

FIOS，即 Flash IO Scheduler，出自 FAST'2012的一篇论文 FIOS: a fair, efficient flash I/O scheduler，致力于解决在 NAND Flash 上存在的公平性问题。我们知道 Linux 已有一个着重公平性的 IO 调度器：CFQ，并且已经发展的非常成熟，那为何又出来一个 FIOS 呢，且听我一一道来。

Femu 来自于 fast-18 上发布的一篇论文The CASE of FEMU: Cheap, Accurate, Scalable and Extensible Flash Emulator[1]。首先 Femu 基于 Qemu 虚拟机实现的，在 Qemu 虚拟机中，对模拟 nvme 的模块进行了部分扩展，以支持更加高级别的针对 Lightnvm 的仿真功能。与原生的 Qemu-nvme 相比，Femu 的扩展主要集中在延迟仿真上。

大三【Linux 操作系统】课的实验内容设计二：向内核中插入虚拟块设备。

事情是这样的，课题教学组有位老师抱怨实验无趣，4 个实验课内容从古沿用至今，每学期的助教都是直接拿往届的实验内容去上，都尽量能少一事就少一事，然后再加上已经上了的实验一，是一如既往的“编译内核与添加系统调用”，被班里的大神们抱怨没啥意思。作为萌新的我只能龟缩在角落玩扫雷，并不断的观察着黑下脸的任课老师。大概这位老师觉得被学生看扁了很不爽吧，次日五个教学班的助教都被召集，要求在一周内设计出有意思的实验内容，并要求附上实验操作手册。于是就有了这篇麻烦。权当做个记录。

该文档描述了 UFS Host Controller 的主要运作流程以及 qemu 中，host controller 的接口函数设计。该文档的内容均参考自 JEDEC STANDARD JESD223C 标准配置文档以及 qemu 中设备模拟源代码。

这篇 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。