FIOS 调度器实现
核心数据结构分析fios 队列结构：struct fios_queue { pid_t pid; // 进程的pid struct rb_node fiosq_node; // 将fios queue插入到fios rb-tree，主要用于在dispatch阶段，快速的取出下一个要被处理的fios queue struct rb_node
FIOS 调度器的实现思路整理
时间片管理CFQ的时间片管理CFQ 的时间片管理如下图。每个请求队列 cfq queue 的时间片用完后，都要通过【选择 cfq group -> 选择 service tree -> 选择 cfq queue】的流程，从其自身维护的数据结构中找出下一个要被调度的请求队列，整个选择相当于根据一个优先级顺序不断地遍历这个数据结构。当一个 cfq queue 的时间片用尽，就要等到下一轮遍
CFQ：完全公平排队 IO 调度器结构简析
block layer 的最核心功能可分为两部分——接受上层提交的请求；对请求进行调度。其中 block layer 的入口函数为：submit_bio。如下图所示：文件系统请求提交 - submit_bio接口函数 submit_bio 被调用后，将对 bio 进行合并，然后尝试合并 request，期间会调用调度器中定义的方法，完成合并后，请求将等待被调度。调度阶段，将决定哪个请求被下发执行，
Linux 实验内容设计：向内核中插入虚拟块设备
大三【Linux 操作系统】课的实验内容设计二：向内核中插入虚拟块设备。事情是这样的，课题教学组有位老师抱怨实验无趣，4 个实验课内容从古沿用至今，每学期的助教都是直接拿往届的实验内容去上，都尽量能少一事就少一事，然后再加上已经上了的实验一，是一如既往的“编译内核与添加系统调用”，被班里的大神们抱怨没啥意思。作为萌新的我只能龟缩在角落玩扫雷，并不断的观察着黑下脸的任课老师。大概这位老师觉得被学生看
LightNVM 自顶向下的 IO 通路简析
这篇 IO 通路简析主要偏向于模块之间的衔接，不涉及模块内的细节，主要回答下面的 4 个问题：在何处向请求队列注册 make request function 函数（这里是 pblk_make_rq）在何处调用了（1）注册的 make request function 函数在何处向请求队列注册了 request function 函数（这里是 pci.c 中的 nvme_queue_rq）在何处调
LightNVM - pblk 源码解析（基于 linux-4.12-rc2）
基本结构图下图是 pblk 的结构图，其中给出了 read 请求和 write 请求的操作示意图，以及 pblk 核心的几个数据结构——L2P table、write buffer、write context。关于具体操作的细节我们在后面的小节给出：Buffer 包含两块内容：write buffer 和 write context。write buffer 存储 4KB 为单位(sector)的
LightNVM 简介
LightNVM[1] 是 CNEXLabs 针对 Open Channel SSD（以下简称 OCSSD）在 Linux 内核中的一种实现，分支托管在 GitHub 上，目前能找到最早的提交记录是 2015-10-29。LightNVM 的程序栈由三层组成，每一层都向用户空间提供了 OCSSD 的抽象（即用户可以直接与这三层进行 IO 交互而不用经过文件系统，后面会细提到）。示意图如下图所示：最
LightNVM 测试环境搭建
要使用 Open-Channel SSD，需要得到操作系统内核支持。 随着 LightNVM 的加入，4.4 版本后的 linux 内核都可以支持。该项目仍然处于开发中，最新的源代码可从 https://github.com/OpenChannelSSD/linux 获得。启用了相应的内核支持后，必须满足以下条件：兼容的设备，如 QEMU NVMe 或 Open-Channel SSD，如 CNE