buffer_head bio

1. 概述
系统能够随机访问固定大小数据片的设备称为块设备，这些数据片称作块。另一种基本的设备类型是字符设备。字符设备按照字节流的方式被有序访问，像串口和键盘 都属于字符设备。这两种类型的设备的根本区别在于它们是否可以被随机访问，换句话说，就是能否在访问设备时随意从一个位置跳到另一个位置。
字符设备仅仅需要控制一个位置--当前位置；而块设备访问的位置必须在介质的不同区间前后移动，同时块设备对执行性能的要求很高。如何管理块设备和如何管理队块设备的请求，该部分在内核中被称为块I/O层。

2. 解剖一个块设备
块设备中最小的可寻址单元式扇区。扇区最常见大小是512字节。软件都会用到自己的最小逻辑可寻址单元--块。块是文件系统的一种抽象--只能基于块来访问文件系统。虽然物理磁盘寻址是按照扇区级来进行的，但是内核执行的所有磁盘操作都是按照块进行的。所以，块只能数倍于扇区的大小，但大小不能超过一个页面。
扇区：设备的最小寻址单元，亦称"硬扇区"或"设备块"
块：文件系统的最小寻址单元，亦称"文件块"或"I/O块"

3. 缓冲区和缓冲区头
当一个块被调用内存时，它要存储在一个缓冲区中。每个缓冲区与一个块对应，它相当于是磁盘块在内存中的表示。
所有这些信息都和文件系统的控制信息密切交融，文件系统的控制信息储存在超级快中，超级块是一种包含文件系统信息的数据结构。由于内核在处理数据需要相关的 控制信息，所以每个缓冲区都有一个对应的描述符。该描述符用buffer_head结构体表示，被称为缓冲区头，在文件中定义。
结构体中h_count域表示缓冲区的使用技术。在操作缓冲区头之前，应该增加缓冲区头的引用计数，确保该缓冲区托不会再被分配出去，当完成对缓冲区的操作后，就减少引用计数。
缓冲区头的目的在于描述磁盘块和物理内存缓冲区之间的映射关系。这个结构体在内核中只扮演一个描述符的角色，说明从缓冲区到块的映射关系。也说明其所描述块的状态(脏，干净，过期等)。它并不与底层的块驱动程序打交道。也就是说它现在只是使得内核了解各个块的状态，而当内核需要提交这些块是，就使用bio，bio根据buffer_head描述的各个块的状态，将相应的块收集起来交给底层驱动程序。因此bio现在是上层与下层连接的纽带，它既包含了上层内存的信息，也包含了下层磁盘的信息。

      在2.6内核以前，缓冲区头的作用比现在还要重要。因为缓冲区头作为内核中的I/O操作单元，不仅仅描述了从磁盘块到物理内存的映射，而且还是所有块I/O操作的容器。可是，将缓冲区头作为I/O操作单元带来了两个弊端。首先，缓冲区头是一个很大且不易控制的数据结构体（现在是缩减过的了），而且缓冲区头对数据的操作既不方便也不清晰。对内核来说，它更倾向于操作页面结构，因为页面操作起来更为简便，同时效率也高。使用一个巨大的缓冲区头表示每一个独立的缓冲区（可能比页面小）效率低下，所以在2.6版本中，许多I/O操作都是通过内核直接对页面或地址空间进行操作来完成，不再使用缓冲区头了。缓冲区头带来的第二个弊端是：它仅能描述单个缓冲区，当作为所有I/O的容器使用时，缓冲区头会迫使内核打断对大块数据的I/O操作（比如写操作），使其成为对多个 buffer_head结构体进行操作。这样做必然会造成不必要的负但和空间浪费。所以2.5开发版内核的主要目标就是为块I/O操作引入一种新型、灵活并且轻量级的容器，也就是要介绍的bio结构体。同时也对buffer_head结构做了简化，让它描述从磁盘块到物理内存的映射信息。而用新定义的为bio的结构体作为块I/O操作的容器。也既，将原来由buffer_head一个结构来完成的工作，现在由buffer_head和bio共同来完成。现在，buffer_head只给上层提供有关其所描述的块的当前状态，而bio则负责将尽可能多的块合并起来，传递给下层驱动程序，并最终写入硬盘。也即，buffer_head负责描述磁盘块到物理内存的映射，bio负责所有块I/O操作的容器。该结构被传递给I/O代码，代码会把它合并到一个已经存在的request结构中，或者根据需要，再创建一个新的request结构。bio结构包含了驱动程序执行请求的全部信息，而不必与初始化这个请求的用户空间的进程相关联。

2.6.29 kernel关于buffer_head前面的注释

/*
 * Historically, a buffer_head was used to map a single block
 * within a page, and of course as the unit of I/O through the
 * filesystem and block layers.  Nowadays the basic I/O unit
 * is the bio, and buffer_heads are used for extracting block
 * mappings (via a get_block_t call), for tracking state within
 * a page (via a page_mapping) and for wrapping bio submission
 * for backward compatibility reasons (e.g. submit_bh).
 */

4. bio结构体
目前内核中块I/O操作的基本容器由bio结构体表示，定义在中。该结构代表了正在现场(活动)的以片段(segment)链表形式组织的块I/O操作。一个片段是一小块连续的内存缓冲区。通过片段来描述缓冲区，即使一个缓冲区分散在内存的多个位置上，bio结构体也能对内核保障I/O操作的执行。像这样的向量I/O就是所谓的聚散I/O。
bio结构体中最重要的几个域是bi_io_ves、bi_vcnt、和bi_idx。
总之，每一个块I/O请求都是通过一个bio结构体表示。每个请求包含一个或多个块，这些块储存在bio_vec结构体数组中。

buffer head用来管理每一个文件块，指向buffer page所包含的buffer；每个buffer包含几个连续的sector。每个块设备传输的request中包含至少一个bio，每个bio都包含几个bio_vec，每个bio_vec都包含一个segment（ulk3中这么称呼），每个segment包含几个连续的buffer。 要写盘时，通过buffer_head为bio结构体赋值，以保证io操作能正确执行。


简言之，buffer_head是用来管理buffer，而bio是用来传输buffer的。bio为通用层的主要数据结构，既描述了磁盘的位置，又描述了内存的位置，是上层内核vfs与下层驱动的连接纽带。

4.1. 缓冲区头与bio结构体对比
bio结构体代表的是I/O操作，它可以包括内存中的一个或多个页；另一方面，buffer_head结构体代表的是一个缓冲区，它描述的仅仅是磁盘中的一个块。bio结构体是轻量级的，它描述的块可以不需要连续存储区，并且不需要分割I/O操作。
利用bio结构体代替buffer_head结构体的好处：
1) bio结构体很容易处理高端内存，因为它处理的是物理页而不是直接指针
2) bio结构体既可以代表普通页I/O，也可以代表直接I/O
3) bio结构体便于执行分散-集中块I/O操作
4) bio结构体比缓冲区头属于轻量级的结构体。因为它只需要包含块I/O操作所需的信息，不用包含与缓冲区本身相关的不必要信息
但是，还是需要缓冲区头这个概念，毕竟它还要负责描述磁盘块到页面的映射。

5. 请求队列
块设备将它们挂起的块I/O请求存在请求队列中，该队列由request_queue结构体表示，定义在中，包含一个双向请求队列以及相关控制信息。通过内核中像文件系统这样高层的代码将请求加入到队列中。请求队列只要不为空，队列对应的块设备驱动程序就会从队列头获取请求，然后将其送入对应的块设备上去。

6. I/O调度程序
磁盘寻址是整个计算机中最慢的操作之一，为了优化寻址操作(尽量缩短寻址时间)，内核既不会简单地按请求接收次序，也不会立即将其提交给磁盘。相反，它会在提交前，先执行名为合并与排序的预操作，在内核中负责提交I/O请求的子系统称为I/O调度程序。
I/O 调度程序是将磁盘I/O资源分配给系统中所有挂起的块I/O请求。具体的说，这种资源分配时通过将请求队列中挂起的请求合并和排序来完成的。而进程调度程序的作用是将处理器资源分配给系统中的运行进程。进程调度程序和I/O调度程序都是将一个资源虚拟给多个对象，对于进程调度程序来说，处理器被虚拟并被系统中的运行进程共享。而I/O调度程序虚拟块设备给多个磁盘请求，以便降低磁盘寻址时间，确保磁盘性能的最优化。

6.1. I/O调度程序的工作
I/O调度程序的工作是管理块设备的请求队列。它决定队列中的请求排列顺序以及在什么时刻派发请求道块设备。这样做有利于减少磁盘寻址时间，从而提高全局(可能存在对某些请求不公)吞吐量。I/O调度程序通过两种方法来减少磁盘寻址时间：合并与排序。
合并指将两个或多个请求结合成一个新请求。当文件系统提交请求到请求队列--从文件中读取一个数据区，如果此时队列已经存在一个请求，它访问的磁盘扇区和当前请求访问的磁盘扇区相邻，那么这两个请求可以合并为对一个对单个和多个相邻磁盘扇区操作的新请求。因此，合并请求显然能减少系统开销和磁盘寻址次数。
假设在读请求被提交给请求队列的时候，队列中并没有其他请求需要操作相邻的扇区，此时就无法将当前请求与其他请求合并，这是就需要排序。排序就是如果存在一个请求，它要操作的磁盘扇区位置与当前请求的比较接近，就让这两个请求在队列上也相邻，整个请求队列将按扇区增长方向有序排列。这样，通过保持磁头以直线方向移动，缩短了所有请求的磁盘寻址时间。

6.2. Linus电梯
在2.4内核中，Linus电梯时默认的I/O调度程序，它能执行合并与排序处理。
合并：当有新的请求加入队列时，它首先会检查其他每一个挂起的请求是否可以和新请求合并。如果新请求正好连在一个现存的请求前，就是向前合并；相反如果新请求直接连在一个现存的请求后，就是向后合并。
排序：如果合并失败，就需要寻找可能的插入点(新请求在队列中的位置必须符合请求以扇区方向有序排序的原则)。如果找到，新请求就被插入该点；如果没有合适的位置，就被插入队列尾部。另外，如果发现队列中有驻留时间过长的请求，那么新请求将被加入到队列尾部，即使插入后也要排序。
缺陷是该算法并非是给等待了一段时间的请求提供实质性服务，这最终会导致请求饥饿现象发生。例如，一个对磁盘同一位置操作的请求可以造成较远位置的其他请求永远得不到运行的机会。

6.3. 最终期限I/O调度程序
最终期限(deadline)I/O调度程序是为了解决Linus电梯锁带来的饥饿问题而提出的。
写操作通常是在内核有空时才将请求提交给磁盘的，写操作和提交它的应用程序异步执行；读操作具有同步性，并且彼此之间往往相互依靠，所以读请求响应时间直接影响系统性能。因此，2.6内核新引入了最后期限I/O调用程序。注意，减少饥饿现象必须以降低全局吞吐量为代价。
在最后期限I/O调度程序中，每个请求都有一个超时时间。默认下，读请求的超时时间是500毫秒，写请求的超时时间是5秒。该调度程序有三个队列：一是排序队列，以磁盘物理位置为次序来维护请求队列。当一个新请求递交给排序队列时，最后期限I/O调度程序类似Linus电梯，合并和插入请求，同时也会以请求类型为依据将它们分别插入到读请求FIFO队列和写请求FIFO队列。如果在这两个队列中的请求超时，那么最终期限I/O调度程序便从FIFO队列中提取请求进行服务。
最终期限I/O调度程序的实现在drivers/block/deadline-iosched.c中。

6.4. 预测I/O调度程序
最终期限I/O调度程序为了降低读操作相应时间做了很多工作，但是它降低了系统吞吐量。比如，系统处于繁重的写操作期间，每次提交读请求，I/O调度程序就迅速处理读请求，然后返回在执行写操作，并且对每个读请求都重复这个过程。其中两次寻址操作却损害了系统全局吞吐量。预测(Anticipatory) I/O调度程序的目标就是在保持良好的读响应时间的同时也能提供良好的全局吞吐量。
预测I/O调度程序的基础是最终期限I/O调度程序。预测I/O调度程序耶实现了三个队列(加上一个派发队列)，并为每个请求设置了超时，它的主要改进是增加了预测启发 (anticipation-heuristic)能力。试图减少在进行I/O操作期间，处理新到的读请求所带来的寻址数量。与最终期限I/O调度程序最大的不同在于，请求提交后并不直接返回处理其他请求，而是有意空闲片刻(默认6毫秒)。这几毫秒，对应用程序来说是个提交其他读请求的好机会，任何对相邻磁盘位置操作的请求都会立刻得到处理。

6.5. 完全公正的排队I/O调度程序
完全公正的排队I/O调度程序(Complete Fair Queuing，简称CFQ)是为了专有工作负荷设计的。CFQI/O调度程序把进入的I/O请求放入特定的队列中，这种队列是根据引起I/O请求的进程组织的。在每个队列中，刚进入的请求与相邻的请求合并在一起，并进行插入分类，队列由此按扇区方式能分类。CFQI/O调度程序的差异在于每一个提交I /O请求的进程都有自己的队列。
CFQI/O调度程序以时间片轮转调度队列，从每个队列中选取请求数(默认是4)，然后进行下一轮调度。
I/O调度程序实现在drivers/block/cfq-iosched.c中。

6.6. 空操作的I/O调度程序
空操作(Noop) I/O调度程序，基本是一个空操作，不做什么事。空操作I/O调度程序不进行排序，只做合并。这种算法并不是没有意义，因为它打算用在块设备。如果块设备只有一点活没有寻道的负担，就没有必要进行排序。
空操作I/O调度程序实现位于drivers/block/noop-iosched.c中，它是专为随机访问设备而设计的。

------------------------

page cache and buffer cache

buffer cache：当一个块被调入内存时，它首先存放在一个缓冲区中，每个缓冲区与一个块对应，它相当于磁盘块在内存中的表示，每个缓冲区都有一个对应的描述符，叫做buffer_head。缓冲区头的目的在于描述磁盘块和物理内存缓冲区之间的映射关系。因此，缓冲区头作为I/O操作的单元，不仅描述了从磁盘到物理内存的映射，而且还是所有块I/O操作的容器。但是，2.6中，I/O操作系统基本容器变为bio结构了。

Page Cache是由内存中的物理页组成的，缓存中的每一页对应着磁盘中的多个块。其核心数据结构为address_space。在执行I/O操作，比如 read（）操作，内核首先会检查数据是否已经在页高速缓存中，如果在，那么内核就可以马上从页高速缓存中得到所需要的页，而不需要从磁盘中读取数据了。 buffer cache 和page cache的联系：page cache它是VFS的需要，buffer cache它是面向设备的，buffer cache是以块为单位的，属于设备驱动层，page cache是以页为单位的，属于文件系统层，策略不同，联系不同，还可能没联系，内核中在多处使用了page cache策略，比如页面交换、磁盘 文件的读取。

> 1 他们针对的对象不同。buffer cache 是供驱动使用， 而 page cache 是供vfs使用。

对于2.6来说，驱动也不一定用buffer cache ，已经流行用bio了。所谓的submit_bh()也会转化成bio。

> 2 他们存的内容不同。buffer cache 存放的是文件的元数据，而page cache 存放的是inode的内容，即文件的数据

错误(也许，对于2.4来说，如果把元数据的cache叫做buffer cache的话，是这样的)。

无论是文件的元数据，还是文件的内容，都可以用buffer来进行IO。
其实，所谓的buffer cache，是和linux的发展变化有关系的，
早期(<=2.4)，linux的所有IO都是以buffer_head（及对应buffer，即1/4 page）为单位，
(1)对于metadata，每个buffer_head是单独读出来，内核对这些buffer维持一个buffer cache。
即使磁盘上相邻的两个buffer，在buffer cache中可能都是不连续的。
(2)而对于file content，是以4个buffer合在一个page里面，因此，文件内部逻辑上相邻的buffer都在一个page里。

2.6以后，file content没有变化，而metadata有变化。
在2.6中，文件的元数据，是通过/dev/sda1这样的raw block device文件来读写，
这些数据对应的buffer，也在page cache中，并且，磁盘上相邻的两个buffer，在page cache中也是相邻的。
因此，在2.6中，应该已经没有buffer cache这个东西了。

在2.6中，已经越来越不提倡使用buffer_head，而是鼓励使用bio，因为bio可以一次提交多个page的IO请求。

但由于legacy的代码，是否使用buffer_head，这似乎和具体的文件系统有关系，比如ext2/ext3。
而ext3在某些条件下，也可以用nobh_xxxx()，也就是说可以不用buffer_header。
而XFS，似乎已经全部转到bio。