块设备是Linux三大设备之一，其驱动模型主要针对磁盘，Flash等存储类设备，块设备（blockdevice）是一种具有一定结构的随机存取设备，对这种设备的读写是按块(所以叫块设备)进行的，他使用缓冲区来存放暂时的数据，待条件成熟后，从缓存一次性写入设备或者从设备一次性读到缓冲区。作为存储设备，块设备驱动的核心问题就是哪些page->segment->block->sector与哪些sector有数据交互，本文以3.14为蓝本，探讨内核中的块设备驱动模型。

下图是Linux中的块设备模型示意图，应用层程序有两种方式访问一个块设备：/dev和文件系统挂载点，前者和字符设备一样，通常用于配置，后者就是我们mount之后通过文件系统直接访问一个块设备了。

作为一种存储设备，和字符设备相比，块设备有以下几种不同：

此外，大多数情况下，磁盘控制器都是直接使用DMA方式进行数据传送。

就是电梯算法。我们知道，磁盘是的读写是通过机械性的移动磁头来实现读写的，理论上磁盘设备满足块设备的随机读写的要求，但是出于节约磁盘，提高效率的考虑，我们希望当磁头处于某一个位置的时候，一起将最近需要写在附近的数据写入，而不是这写一下，那写一下然后再回来，IO调度就是将上层发下来的IO请求的顺序进行重新排序以及对多个请求进行合并，这样就可以实现上述的提高效率、节约磁盘的目的。这种解决问题的思路使用电梯算法，一个运行中的电梯，一个人20楼->1楼，另外一个人15->5楼，电梯不会先将第一个人送到1楼再去15楼接第二个人将其送到5楼，而是从20楼下来，到15楼的时候停下接人，到5楼将第二个放下，最后到达1楼，一句话，电梯算法最终服务的优先顺序并不按照按按钮的先后顺序。Linux内核中提供了下面的几种电梯算法来实现IO调度：

我们可以通过内核传参的方式指定使用的调度算法

或者，使用如下命令改变内核调度算法

VS左面的是数据交互中的内存部分，Page就是内存映射的最小单位; Segment就是一个Page中我们要操作的一部分，由若干个相邻的块组成; Block是逻辑上的进行数据存取的最小单位，是文件系统的抽象，逻辑块的大小是在格式化的时候确定的, 一个 Block 最多仅能容纳一个文件（即不存在多个文件同一个block的情况）。如果一个文件比block小，他也会占用一个block，因而block中空余的空间会浪费掉。而一个大文件，可以占多个甚至数十个成百上千万的block。Linux内核要求 Block_Size = Sector_Size * (2的n次方)，并且Block_Size <= 内存的Page_Size(页大小）, 如ext2 fs的block缺省是4k。若block太大，则存取小文件时，有空间浪费的问题；若block太小，则硬盘的 Block 数目会大增，而造成 inode 在指向 block 的时候的一些搜寻时间的增加，又会造成大文件读写方面的效率较差，block是VFS和文件系统传送数据的基本单位。block对应磁盘上的一个或多个相邻的扇区，而VFS将其看成是一个单一的数据单元，块设备的block的大小不是唯一的，创建一个磁盘文件系统时，管理员可以选择合适的扇区的大小，同一个磁盘的几个分区可以使用不同的块大小。此外，对块设备文件的每次读或写操作是一种"原始"访问，因为它绕过了磁盘文件系统，内核通过使用最大的块(4096)执行该操作。Linux对内存中的block会被进一步划分为Sector，Sector是硬件设备传送数据的基本单位，这个Sector就是512byte，和物理设备上的概念不一样，如果实际的设备的sector不是512byte，而是4096byte(eg SSD)，那么只需要将多个内核sector对应一个设备sector即可

VS右边是物理上的概念，磁盘中一个Sector是512Byte，SSD中一个Sector是4K

同样是面向对象的设计方法，Linux内核使用gendisk对象描述一个系统的中的块设备，类似于Windows系统中的磁盘分区和物理磁盘的关系，OS眼中的磁盘都是逻辑磁盘，也就是一个磁盘分区，一个物理磁盘可以对应多个磁盘分区，在Linux中，这个gendisk就是用来描述一个逻辑磁盘，也就是一个磁盘分区。

gendisk是一个动态分配的结构体，所以不要自己手动来分配，而是使用内核相应的API来分配，其中会做一些初始化的工作

上面几个API是一个块设备驱动中必不可少的部分，下面的两个主要是用来内核对于设备管理用的，通常不要驱动来实现

这两个API最终回调用kobject *get_disk() 和kobject_put()来实现对设备的引用计数

和字符设备一样，如果使用/dev接口访问块设备，最终就会回调这个操作方法集的注册函数

每一个gendisk对象都有一个request_queue对象，前文说过，块设备有两种访问接口，一种是/dev下，一种是通过文件系统，后者经过IO调度在这个gendisk->request_queue上增加请求，最终回调与request_queue绑定的处理函数，将这些请求向下变成具体的硬件操作

从驱动模型的角度来说, 块设备主要分为两类需要IO调度的和不需要IO调度的, 前者包括磁盘, 光盘等, 后者包括Flash, SD卡等, 为了保证模型的统一性 , Linux中对这两种使用同样的模型但是通过不同的API来完成上述的初始化和绑定

针对请求队列的操作是块设备的一个核心任务, 其实质就是对请求队列操作函数的编写, 这个函数的主要功能就是从请求队列中获取请求并根据请求进行相应的操作 内核中已经提供了大量的API供该函数使用

bio用来描述单一的I/O请求，它记录了一次I/O操作所必需的相关信息，如用于I/O操作的数据缓存位置，，I/O操作的块设备起始扇区，是读操作还是写操作等等

描述指定page中的一块连续的区域，在bio中描述的就是一个page中的一个"段"(segment)

用于记录当前bvec被处理的情况，用于遍历bio

遍历一个request中的每一个bio

遍历一个bio中的每一个segment

遍历一个request中的每一个segment

遍历request_queue，绑定函数的一个必要的工作就是将request_queue中的数据取出, 所以遍历是必不可少的, 针对有IO调度的设备, 我们需要从中提取请求再继续操作, 对于没有IO调度的设备, 我们可以直接从request_queue中提取bio进行操作, 这两种处理函数的接口就不一样，下面的例子是对LDD3中的代码进行了修剪而来的，相应的API使用的是3.14版本，可以看出这两种模式的使用方法的不同。